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I.  IWTRODDCTION 


Recognizing  tne  relatlonsolp  between  policies  and 
mecnanlsns  nas  neen  a  problem  In  tne  specification  and 
deslen  of  many  computer  systems.  Vnat  Is  needed  is  a  simple 
metbodology  for  assessing  tne  suitability  of  a  protection 
mecbanlsm  to  enforce  a  non-dlscretlonary  security  policy. 
Sucb  a  metbodologyt  based  upon  tne  entity-relationship  model 
and  designed  wltb  validation  of  security  enforcement  as  its 
primary  objective*  Is  presented. 

Defined  as  the  assignment  technique*  this  mathematically 
oriented  metbodology  establishes  a  relationship  between  tne 
Information  sensitivities  of  the  systems  entitles 
(partitioned  according  to  tne  policy  constraints),  to 
dominance  domains  (Inherently  established  by  a  mechanism). 
The  assignment  technique  provides  a  means  for  mecnanlsm 
sufficiency  validation,  since  tne  results  of  tne  assignment 
can  be  evaluated  to  determine  whether  tne  constraints  of  tne 
policy  are  met. 

Mechanisms  are  defined  as  procedural  specifications  that 
prevent  the  occurrence  of  operations.  Protection  mechanisms, 
then  control  a  subject's  access  to  an  object,  by  adhering  to 
some  procedural  specification  of  access  rules.  Policies, 
however,  are  generally  stated  la  a  non-procedural  form.  This 
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leads  to  a  problem  in  translating?  policies  into  mecnanisms, 
and  in  verifying  the  accuracy  of  tuis  translation. 

Only  non-dlscretlonary  security  policies  are  discussed 
In  detail.  SucU  policies,  nowever,  are  extremely  Important 
vnen  dealin?  wltn  protection  of  business  information  as  veil 
as  National  Security.  Computer  systems  designed  to  provide 
Command,  Control  and  Communications  must  rely  upon  effective 
non-dlscretlonary  security  If  tney  are  to  be  of  any  value  to 
National  Defense  [ij .  Compromise  and  subversion  policies  [2J 
precisely  define  tne  requirements,  but  tfte  suitability  of  a 
protection  mecnanlsm  to  meet  tnese  requirements  is  not 
always  apparent.  A  tneoretlcal  foundation  from  wnicn  tnls 
suitability  may  be  simply  and  readily  derived  Is 
establlsned. 

A.  DACAGROaND 

Non-dlscretlonary  policies  for  tne  security  of  sensitive 
Information  nave  existed  tnrou^nout  tne  annals  of  nistory. 
The  basis  of  these  policies  lies  in  a  subject  (l.e.,  an 
active  entity)  beln«  prohibited  modification  or  observation 
of  an  object  (l.e.,  a  repository  for  Information  or  Inactive 
entity)  based  upon  the  subject's  membership  In  a  specified 
arroup.  This  erouplne  is  established  external  to  tne  system 
In  which  It  will  be  used. 

The  first  computer  systems  dealt  with  the  problem  of 
security  by  establishing  physical  protection  perimeters. 
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Walls,  locSs  and  marines  with  rifles  provided  the 
environment  necessary  for  system  security.  Tnis  was  an 
acceptable  procedure  because  there  were  relatively  few  users 
of  tne  system  and  eacn  user  was  trusted  not  to  violate  tne 
security  policies.  Security  was  an  issue  external  to  tae 
computer  Itself, 

However,  as  computer  technology  became  more 
sophisticated,  user  expectations  increased.  Pollcy-maxers 
established  security  policies  and  expected  their  machines  to 
adhere  to  them  without  exception.  The  security  perimeters 
that  had  been  established  external  to  tne  computer,  were  now 
to  be  established  internally. 

This  led  to  two  fields  of  research.  One  group,  tne 
experimentalists,  attempted  to  design  ingeniously  contrived 
mecnanlsms  with  little  or  no  concern  for  tne  policies  wnlcn 
their  mechanism  would  support.  Mathematicians,  on  the  other 
hand,  set  about  tne  tash  of  modeling  policies  in  a  fasnlon 
that  would  establish  a  foundation  for  the  procedural 
specification  of  protection  mechanisms.  The  relationship 
between  these  models  and  the  mechanisms  was  not  always 
clear. 

What  is  needed,  and  wnat  Is  presented  nere,  is  a  simple, 
complete  and  consistent  means  of  establishing  that  a 
mecnanlsm  actually  enforces  tne  pollcy-mahers ' 
specifications.  This  Is  done  by  first  giving  the 
pollcy-mairer  a  tool  to  precisely  describe  nls  policy  and 
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tben  giving  tne  systems  designers  and  analysts  a  ternnlque 
to  evaluate  the  sufficiency  of  their  mechanism  to  support 
tnls  policy. 

A  careful  examination  of  tne  fundamental  nature  of 
non-dlscretlonary  security  policies  and  protection 
mecnanlsms  Is  made.  This  examination  Is  Cased  largely  upon 
the  flndlnes  of  research  associated  with  security  kernel 
tecnnology  [3j .  Tne  results  of  tnls  examination  snow  wnat  it 
is  about  mechanisms  that  actually  provides  tne  protection 
and  what  protection  Is  actually  provided.  In  so  doin^,  a 


theoretical  mathematical  foundation  Is  established 
which  the  science  of  secure  computation  may  proceed  to 
tne  requirements  of  tne  poilcy-mater  In  a  simple,  el 
and  efficient  manner. 


from 
mee  t 
egant 


B.  RELATED  WORK 

Research  In  establishing  the  suitability  of  protection 
mecnanlsms  to  meet  non-discretlonary  security  policies  is 
practically  non-existent.  Protection  mecnanlsms  are  usually 
presented  in  an  informal  manner  with  implementation  details 
dominating  tne  discussion  [4j .  Policies,  on  tne  other  nand, 
are  generated  by  persons  wno  rarely  give  consideration  to 
the  Implementation  of  these  policies  In  a  computer  system. 
Tne  disparity  between  tnese  two  groups  nas  led  to  little 
research  In  methodologies  for  bridging  the  broad  gap  between 
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security  policies  and  protection  mecnanlsirs,  and  even  less 
results. 

Tae  notion  of  aomalns  origlnatea  wltn  Dennis  and  Van 
Horn  [5J  and  tneir  concept  of  spneres  of  protection.  Tnis 
idea  was  liiproved  upon  by  Lampson  wno  coined  ttie  term 
"donaln”  and  noted  tne  usefulness  of  domains  as  a  conceptual 
tool  for  understanding  protection  mecaanlsms.  Scaroeder  [bj 
made  use  of  tnese  ideas  to  design  a  protection  mecnanism 
taat  would  allow  mutually  suspicious  subsystems  to  cooperate 
in  a  single  computation. 

Popes  [9J  modeled  tne  nature  of  access  control  wi tn  ni s 
restriction  erapns.  Bell  and  LaPadula  I10j  made  a 
significant  contribution  wnen  tney  identified  a  matnematicai 
frameworS  wltaln  walca  to  deal  wlta  tae  problems  of  secure 
computer  systems.  Tneir  wors  was  based  upon  general  systems 
taeory  and  finite  state  automata.  FurteS  [llj  estatiisned  a 
similar,  less  snown,  matnematicai  frameworic  based  upon  tae 
theory  of  constraints.  Tne  Beil  and  LaPaauia  worlc  was 
followed  by  Walters  [12j  development  of  a  lattice  model  for 
security  policies.  This  model  was  refined  and  later 
popularized  by  Oennincr  [13]  such  that  today,  nearly  all 
practical  policies  nave  been  recognized  as  lattice  policies. 

Saltzer  and  Schroeder  114]  presented  a  tutorial  on  tae 
basic  principles  of  protection  in  computer  systems.  Conen 
[15],  however,  provides  a  far  more  rleorous  discussion  of 
protection  mechanisms  while  Groans'  [16]  research  provides 
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considerable  Inslgnt  Into  a  number  of  details  regarding 
access  relations. 


Mucn 

of 

tnls  early  work  was 

directed 

towards 

tne 

solution 

of 

tne  computer  security 

problem 

In  National 

Defense 

[12, 

17J  .  As  sucn,  tne  autnors 

rarely 

dlscused 

tne 

motivation  for  tneir  efforts.  It  was  Scbeii  lU ,  aowever, 
wno  dramatically  described  tne  Importance  of  tne  computer 
security  in  a  modern  electronic  environment.  Recognition  of 
tne  significance  of  tnls  problem  motivated  tne  researcn 
reported  nere. 

C.  ORGANIZATION 

Tlie  relationsnip  between  security  policies  and 
protection  mechanisms  is  not  obvious.  In  order  to  explore 
this  relationship,  one  must  clarify  tne  meaning  of  security 
and  protection.  Only  by  methodically  examinlae  each  and 
every  pertinent  principle  can  one  nope  to  establish  a 
mathematical  framewort  which  unifies  the  security  policy 
Issues  with  tne  protection  mechanisms'  design. 

The  nature  of  non-discretlonary  security  policies  Is 
considered  first.  Tne  meaning  of  access  relations  is 
explored  and  commonly  known  policies  are  discussed. 

Next,  a  formalized  notion  of  domains  is  presented.  A 
succinct  mathematical  definition  of  a  domain  Is  offered.  The 
notion  of  an  (access-mode)  domain  and  dominance  domains  are 
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introduced  as  tools  for  precisely  cnaracterlzing  protection 
mecbanisms. 

Section  four  discusses  tne  tneoretical  oasis  for 
assignment.  The  assignment  tecnnlque  is  explained  and  a 
means  for  simplifying  tne  tne  number  of  assignment  scnemes 
needed  to  establish  the  Insufficiency  of  a  mechanism  to 
support  some  particular  policy  is  derived. 

Section  five  presents  detailed  applications  of  simple 
assignment  showlne  the  usefulness  of  the  assignment 
tecnnlque  particularly  wltn  respect  to  mecnanism  sufficiency 
validation.  Section  five  dispells  much  of  tne  mystery  that 
surrounds  tne  ad  noc  design  of  secure  computer  systems. 

Every  attempt  has  been  made  to  provide  the  reader  with  a 
clear  understanding  of  the  principles  of  the  assignment 
technique.  Readers  are  encouraged  to  question  these  findings 
and  indeed#  the  fundamentals  upon  which  they  are  based.  Only 
in  so  doing,  can  one  nope  to  grasp  tne  meaning  of  tne 
principles  presented  and  the  utility  of  the  assignment 
technique  in  establishing  a  foundation  for  secure  computer 
systems. 
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II.  non-discretionart  sbcuritt  policies 


TQls  section  provides  a  detailed  examination  as  to  tne 
nature  of  non-dlscrstionary  security  policies  after  first 
discussing  several  pertinent  concepts  concerning  policies  In 
general.  Some  of  tne  Issues  presented  may  appear  to  confuse 
policy  Issues  wltn  mecnanlsm  issues.  Hopefully,  tnis 
confusion  will  pe  resolved  as  tne  reader  obtains  a  tnorough 
understanding  of  tne  Innerently  Isomorpnic  nature  of 
policies  and  mechanisms,  as  substantiated  In  tne  ensuing 
discussion. 

A.  THE  NATORE  OP  A  POLICY 

The  fundamental  nature  of  a  policy  nas  not  been  clearly 
establlsned  In  tne  Computer  Science  field.  For  example, 
Wulf,  Cohen,  Jones  and  others  sueeest  that  a  policy  is  a 
mecnanlsm  wnen  discussing  HYDRA  [IHJ .  Jones  subsequently 
discusses  how  protection  mechanisms  can  be  used  to  enforce 
security  policies  [19J .  On  tne  otner  nand,  Conen  defines  a 
policy  as  a  problem  In  his  doctoral  dissertation  [15]  but, 
enumerates  several  protection  problems  associated  wltn  one 
security  policy  Cl5J .  Such  confusion  among  such  a  closely 
related  group  of  computer  scientists  specializing  in 
operating  system  security  Is  by  no  means  an  Isolated 
situation. 
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Snyder  [20J  mases  note  of  tnis  problem  stating  mat 


capablll ty-based  protection  systems  designers  rarely 
consider  tbe  security  policies  tneir  system  may  implement. 
Tnrougnout  tne  computer  security  literature,  one  may  observe 
that  the  nature  of  a  policy  and  now  It  relates  to  tne 
protection  issues  discussed.  Is  often  Ignored.  Pernaps  tnis 
is  because  the  nature  of  security  policies  t fiemseives ,  and 
the  suitability  of  protection  mecnanlsms  to  meet  tnese 
policies  Is  not  clearly  understood.  It  is  the  Intent  of  tnis 
author  to  address  tnis  problem.  In  order  to  do  so,  one 
begins  by  formallzln*  tne  notion  of  a  policy. 

A  policy  is  a  specification  of  benavlor.  Sucn  a 
specification  constrains  tne  activities  within  a  system  by 
establisnlng  a  distinction  between  acceptable  and 
unacceptable  behavior  for  some  set  of  classes  estaoilsned  by 
the  policy,  ifhen  dealing  with  tne  security  issue,  tne 
classes  (l.e.,  access  classes)  are  simply  labels  wnlcn  me 
policy  uses  to  llstlneulsh  between  <?roups  of  system 
entitles.  So  a  security  policy  specifies  a  set  of  access 
classes  and  identifies  tne  acceptable  behavior  between  them. 

Enforcement  of  policies  may  be  realized  in  a  number  of 
ways.  In  eeneral,  any  means  of  security  enforcement  internal 
to  the  computer,  may  be  considered  to  be  a  protection 
mechanism.  As  such,  implementation  details  are  generally 
ignored. 
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Tne  term  behavior  generally  Implies  that  an  active 
entity  is  dealing  wltn  some  otner  entity  or  entities.  So  one 
can  distinguish  between  two  types  of  entitles  with  respect 
to  security  policy  specifications.  One  type  is  those 
entities  whose  benavlor  is  being  controlled.  These  are  tne 
active  entitles  within  the  system  and  are  referred  to  as 
"subjects".  The  otner  type  is  those  wltn  wnicn  tne  subject 
Interacts  during  execution  that  are  not  subjects,  but  rather 
are  simply  repositories  of  information  [12J .  These  are  tne 
passive  entitles  within  the  system  referred  to  as  ’’objects”. 

A  process  is  characterized  by  an  address  space  and  an 
execution  point  or  state  of  Its  virtual  processor,  it  Is 
Important  to  note  tne  distinction  between  processes  and 
subjects  as  these  two  terms  are  often  incorrectly  considered 
to  be  synonyomous.  A  subject  is  Implemented  as  a 
process-domain  pair  [6,7,8].  One  must  talte  care  not  to 
confuse  these  two  terms. 

Much  confusion  has  been  associated  with  the  issue  of 
policy  enforcement.  A  policy  may  be  completely  enforced  in  a 
system,  partially  enforced  in  a  system  or  not  enforced  at 
all.  Partial  enforcement  applies  only  to  complex  policies 
for  Which  sub-policies  can  be  formulated  and  enforced. 
Partial  enforcement  does  not  imply  enforcement  of  a  policy 
only  under  certain  conditions,  or  at  certain  times,  wnicn 
is,  in  fact,  no  enforcement  at  all.  Partial  enforcement 
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refers  to  enforcement  of  a  sub-policy  wltnln  tne  context  of 
the  overall  policy. 

Policies  are  not  problems  [15J  .  Problems  occur  only  in 
the  Implementation  of  a  policy  and  are  used  to  describe 
pitfalls  in  tne  enforcement  of  some  policy  of  interest. 

Applylne  some  policy  to  a  system  mates  no  changes  to 
that  system  at  tne  time  of  application.  Tnls  means  tnat 
policies  do  not  initially  alter  the  entities  with  whir*h  they 
deal.  Rather,  entitles  are  assigned  to  an  access  class 
according  to  the  policy.  If  an  entity  Is  assigned  to  an 
access  class  sucn  tnat  its  attributes  require  modification, 
or  its  relationships  are  invalid,  or  the  entity  Itself  does 
not  belong  within  tne  system,  tne  system  is  not  In 
compliance  with  the  policy.  Action  may  be  taJcen  later  to 
bring  tne  system  Into  compliance,  but  simply  associating  tne 
poller  with  the  system,  in  effect,  only  labels  me  system 
entitles. 

Recognizing  tne  nature  of  a  policy  is  important  if  one 
is  interested  in  enforcement  of  policies  in  computer 
systems.  This  Is  because  tne  logical  nature  of  a  computing 
device  dictates  a  logical  specification  of  policy.  Having 
clearly  described  tne  nature  of  a  policy  in  general,  one  may 
now  examine  security  policies. 


B.  SECOHITT  POLICIES 


Security  policies  are  eeneraiiy  erouped  into  two  broad 
Classes.  Non-dlscretlonary  security  policies  (so:Tietlmes 
referred  to  as  mandatory  policies),  are  policies  wfticfi  fix 
tne  classification  of  information  sensitivities  and 
establisn  ail  permissible  access  relations  (viz.,  subjects 
gaining:  some  form  of  access  to  objects)  according  to  tnese 
information  sensitivities.  Sucn  a  policy  is  generally 
considered  to  externally  constrain  wnat  access  is 
permissible  [3J.  Enforcement  of  a  policy  requires  tnat  tne 
sensitivity  of  all  objects  and  tne  autnorl cat  ions  of  ail 
subjects  be  clearly  Identified. 

Discretionary  policies,  in  a  sense,  provide  a  finer 
granularity  of  access  control  witnln  tne  constraints  of  tne 
non-discretlonary  policies  of  tne  system  [3J  .  Autnorization 
to  access  information  and  specification  of  source 
information  access  classes  are  made  outside  of  tne  computer 
environment.  A  policy  is  discretionary  vnen  a  subject  witn 
access  to  an  object  may  exercise  its  discretion  in  masing 
tnat  object  available  to  some  otner  subject.  As  sucn,  tne 
information  sensitivity  of  an  object  is  decided  in  a 
discretionary  or  arbitrary  manner.  Tnis  tends  to  produce 
"spagbetti  bowl"  policies  where  tne  information 
sensitivities  of  objects  is  not  easy  to  determine.  The 
sensitivity  of  objects  is  constantly  changing  in  an 
arbitrary  manner  which  may  not  be  readily  observable  or 
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controiiabie .  Sucn  policies  are  noi  practical  wnen  aeallng 
wlin  many  of  tne  National  Defense  issues.  Because  of  tneir 
limited  utility,  discretionary  policies  are  not  as 
interestin?  as  non-dlscret  ionary  policies  nor  is  tJieir 
enforcement  sucn  a  critical  issue. 

Only  non-dlscrstlonary  security  policies  are  examined  in 
tnis  discussion.  It  is  snown  tnat  all  non-discretionary 
security  policies  can  be  represented  as  lattice  security 
policies. 

C.  LATTICE  SECORIII  POLICIES 

A  number  of  non-dlscretionary  security  policies  nave 

already  been  described  as  lattice  policies  [12,21J .  As  sucn, 

tne  precise  form  of  tne  lattice  structure  is  helpful  in 

understanding  tne  nature  of  tne  policy  [19J . 

A  universally  bounded  lattice  is  a  mathematical 

structure  consisting  of  a  finite,  partially  ordered  set  for 

which  there  exists  precisely  one  least  common  upper  element 

(i.e,,  tne  least  upper  bound  (LUB))  and  precisely  one 

greatest  common  lower  element  (i.e.,  the  greatest  lower 

bound  (3LB))  [22,23j .  A  partially  ordered  set,  is  a  set,  0, 

for  which  a  relation,  R,  is  applied  to  Q  such  that  R  is 

reflexive,  antisymmetric  and  transitive  [22j .  For  example, 

consider  the  set  Q  »  {  q,,  q .,  q^,  q,  >  and  the  relation  R 

12  3  4 

applied  to  0  such  tnat  related  to  q^  by 

relation  R),  q,Rq,,  q  Rq,  t  q„Rq.  t  and  q  Rq  .  The  relation  R 
131424  34 
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foms  a  lattice  on  tne  set  Q  vita  q  as  toe  GLJj  and  a  as 


When 

discussing 

lattice 

security 

policies,  one 

recognizes 

tne 

set 

0  as 

tne 

set  of 

access  classes 

esta  bllsned 

by 

tne 

policy. 

Tne 

access  relation  fl,  nowever. 

may  vary  significantly  from  policy  to  policy.  Tnls  fact  is 
not  so  well  recognized.  Dennincs  information  flow  model 
Cl3j  ,  for  example,  describes  a  flow  relation,  defined 

on  pairs  of  access  classes  sucn  that  for  classes  A  and  £,  l 
— ^  3  if  and  only  if  information  in  class  A  is  permitted  to 

flow  into  class  B.  Tnls  relation  applies  to  compromise  and 
subversion  policies,  for  example,  out  is  meaningless  wnen 
discussine  proeram  integrity. 

Taree  relations  between  access  classes  are  generally 
sufficient  to  describe  tne  specifications  of  any 
non-dlscretlonary  security  policy.  For  access  classes  A  and 
B,  tnese  are  : 

A  >  B  Information  of  access  class  A 
is  more  sensitive  tnan 
information  of  access  class  B 

A  =  B  Information  of  access  class  A 
is  of  tne  same  sensitivity  as 
information  of  access  class  B 

A  B  Information  of  access  class  A 
is  in  no  way  related  to 
Information  of  access  class  B 

The  notion  of  sensitivity  may  be  easily  confused  wnen 
discussing  several  policies.  Tnis  is  because  tne  term  taxes 
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lis  meanlne  from  the  policy  in  question  ani  cannot  be 
realiiy  associated  witn  two  diverse  policies,  for  erampie, 
an  object  0  may  be  >  a  subject  S  with  respect  to  one  policy, 
w  witn  respect  to  anotner  policy,  and  S  >  0  witn  respect  to 
still  anotner  policy.  Sensitivity,  tnen,  may  not  be  useful 
for  discussin*?  multiple  policy  issues.  It  is  nowever,  a 
useful  intuitive  term  for  describlni?  the  lattice  nature  of  a 
poll cy . 

This  autnor  advances  tne  nypotnesis  that  all 
non-discreti onary  security  policies  may  be  represented  as 
lattice  policies.  A  simple  argument  is  offered  in  support  of 
this  nypotnesis  as  a  complete  proof  nas  not  been  developed. 

Non-dlscretlonary  security  policies  are  established 
external  to  tne  computer  system  environment.  As  suca,  tney 
define  some  form  of  benavlor  between  subjects  and  objects 
from  whlcn  tne  system  may  not  deviate  without  external 
authoritative  approval.  The  system  entities  (i.e.,  the 
subjects  and  objects)  must  be  clearly  labeled  or  otherwise 
identified  with  respect  to  tne  policy.  Grouplne  those  system 
entitles  wnose  labels  are  identical,  one  may  establish  a  set 
of  equivalence  classes  wnicn  completely  partition  the 
systems'  entitles.  One  may  tnint  of  tnese  equivalence 
classes  as  labeled  by  tne  access  classes.  Such  a 
partitioning,  for  all  practical  policies  and  systems  is 
f ini te. 
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One  Day  tnen  examine  tfte  relations  between  access 
classes  wltn  respect  to  tne  policies.  Enumerating  ail  tne 
relations  between  access  classes,  one  may  draw  a  graph,  such 
as  tnat  snown  in  figure  i,  witn  nodes  signifying  access 
classes  and  arcs  signifying  tnat  tne  access  class  of  tne 
higher  node  (l.e.,  closer  to  the  top  of  the  page)  is  more 
sensitive  (>)  tnan  tne  access  class  of  tne  lower  node. 
Transitive  relations  need  not  be  drawn  as  tneir  inclusion  is 
Implicit  and  does  not  affect  tne  grapn. 

Figure  1.  Disjoint  Partially  Ordered  Sets  and  Nodes 

If  any  cycles  are  discovered,  in  an  attempt  to  construct 
tne  grapn,  one  may  see  tnat  tne  specification  of  policy  is 
not  enforceable.  That  is  to  say,  for  some  cycle  of  access 
classes  A  >  B  >  ...  >  Z  >  A,  the  information  sensitivity  of 
some  access  class  A  Is  at  the  same  time  >  A  and  =  A.  This  is 
a  paradox.  Attempting  to  enforce  such  a  specification  is 
intuitively  nonsense!  So  if  one  Is  to  nave  a 
nott-dlscretlonarjr  security  policy,  vlt.,  one  wnlcn  is  to  be 
enforced  in  a  mandatory  fashion,  one  may  safely  assume  that 
the  policy  will  specify  no  cyclic  relations  among  tne  access 
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classes.  Taerefore,  one  iriay  categorically  state  tnat  tne 
graph  of  any  enforceable  non-dlscretlonary  security  policy 
will  never  contain  any  cycles. 

Further  eia.iiining  tne  graph,  one  can  observe  that  only 
two  general  structures  may  exist.  The  first  consists  of 
unrelated  nodes  (i.e.,  those  nodes  which  are  singletons 
representing  access  classes  with  no  relations  to  other 
access  classes  in  the  eraph).  The  other  structures  are 
partially  ordered  sets  (some  of  whlcn  may  be  a  lattice). 


figure  2.  Lattice  Structure 

If  tne  grapn  does  not  contain  a  least  upper  bound, 
(LOB),  one  may  arbitrarily  create  an  access  class  so 
designated  and  establish  tne  appropriate  relations  with 
respect  to  its  sensitivity  (see  figure  2).  This  access  class 
may  also  be  referred  to  as  toe  "system  nign."  Llitewise,  one 
may  do  the  same  for  tne  greatest  lower  bound  (GLB)  which  Is 
generally  Known  as  tne  "system  low,"  Note  tnat,  neltner  tne 
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LUB  nor  tne  SLB  nesa  nave  any  entitles  associated  wltn  tnelr 
access  class.  By  formlne  tnis  structure,  one  nas  establlsr.ei 
a  lattice. 

THUS,  all  non-dlscretlonary  security  policies  are 
lattice  security  policies.  Non-dlscretlonary  security 
specifications  tnat  venerate  cyclic  structures  are  not  well 
forTied  policies  and  as  sucn,  tnelr  enforcement  cannot  ce 
evaluated  nor  can  one  consider  sucn  a  specification  to  be  a 
policy  wortny  of  discussion. 

D.  SIMPLE  LATTICE  SECaRITT  POLICIES 

A  policy  is  a  "simple  lattice  policy"  wnen  tne  policy 
establlsnes  eltner  one  of  two  basic  lattice  structures.  Tne 
first  structure  is  formed  by  a  simply  ordered  (viz., 
linearly  ordered  or  totally  ordered)  set  of  access  classes. 
For  example,  some  policy  mignt  establlsn  a  simply  ordered 
structure  wnere  SECRET  Is  more  sensitive  than  (>) 
CONFIDENTIAL  >  UNCLASSIFIED.  Policies  wltn  simply  ordered 
sets  of  access  classes  are  called  "tie rarcnlcal  policies." 

Tne  otner  basic  lattice  structure  is  formed  by  a 
mutually  exclusive  set  of  access  classes.  For  example,  some 
policy  migttt  establlsn  a  mutually  exclusive  structure  wnere 
CRTPTO  is  not  related  to  (#)  NATO  n  NUCLEAR.  Those  policies 
wltn  mutually  exclusive  sets  are  called  "category  policies." 
One  should  note  that,  a  "compartment"  access  class,  e.«., 
CRIPTO-NATO,  is  formed  wnen  some  restricted  form  of  access 
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Is  dvaiiabie  to  two  or  Tiore  otnerwise  mutually  exclusive 
categories  of  information. 

Recall  t&at  a  lattice  security  policy  partitions  toe 
systems  entitles  witn  respect  to  tneir  information  sensitiv¬ 
ities,  into  a  set  of  equivalence  classes  tnat  can  be  labeled 
by  tne  access  classes.  Consider  any  two  lattice  security 
policies,  and  and  some  system  containing  a  non-empty 
set  of  entitles,  A.  tfnen  P^  Is  applied  to  tne  system, 
a  partition,  is  estabilsned  creatine  tne  set  of 


equivalence  classes 

.  { 

• 

•  • ,  ,  • 

•  •  * 

e  } 
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by 

tne 
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policy  P. 

It  readily  follows  tnat  all  lattice  security  policies 
are  the  prodirct  of  one  or  more  simple  lattice  policies.  The 
total  non-dlscretlonary  security  pacJcage  for  a  system  then, 
consists  of  some  set  of  simple  lattice  security  policies 
successively  refining  tne  systems  entities,  none  of  wnicn 
may  produce  conflicting  policies.  This  is  shown  to  be 
particularly  useful  knowledge  when  one  attempts  to  use  tne 
assignment  technique  as  a  means  of  security  validation. 
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B.  ACCESS  RELATIONS 

Aay  specific  noD-dlscretlonary  security  policy  will 
dlstlnguisa  one  or  mors  distinct  access  relations  between 
subjects  and  objects.  Associated  witn  tnese  distinctions  one 
may  derive,  wnere  not  otaerwise  specified,  tae  set  of 
"access  rl^nts”  wnicn  may  be  accorded  to  tne  subject.  Tnese 
access  rl?nts  specify  tne  liberties  walca  tne  subjects  may 
tase  witn  respect  to  tnese  objects.  Access  rl^nts  are 
typically  mirrored  in  tne  "access  modes”  of  tne 
correspondine  protection  mecnanlsm.  Altnouen  tnere  exists  a 
fine  difference  between  an  "access  rlgnt"  and  an  "access 
mode",  vlx,,  "access  rlK&ts"  are  associated  with  security 
policies  aud  "access  nodes"  are  associated  witn  tne 
protection  mechanisms  wnicn  enforce  tne  policy,  this 
discussion  frequently  refers  to  an  "access  rlgnt"  as  an 
"access  mode"  because  it  Is  tne  access  mode  wnicn  must 
inevitably  be  questioned  when  evaluating'  the  enfor''ement  of 
a  securl ly  policy  . 

The  enforcement  of  a  policy  Is  fundamentally  limited  by 
tne  system's  granularity  of  access  wnicn  may  also  be  tnougnt 
of  as  the  system's  variety  or  richness  of  access  modes. 
Policies  mat  prescribe  distinctions  not  recognized  by  tne 
access  control  mechanisms  must  be  enforced  In  an  overly 
restrictive  manner  or  Ignored.  For  example,  a  policy 
addressing  a  concatenation  access  relation  cannot  be 
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precisely  enforcel  on  a  systein  that  does  not  rerosnlze  soTe 
forn  of  append  access  mode. 

The  basis  of  ail  security  enforcement  evaluation  lies  in 
tne  acceptability  of  an  access  relation.  An  access  relation 
is  defined  as  a  tuple  (subject,  access  mode,  object).  This 
tuple  signifies  tnat  a  relation  between  tne  subject  and 
Object  exist  sucn  tnat  tne  subject  is  permitted  to  access 
tne  object  witn  all  tne  privileees  associated  with  the 
access  mode.  The  problem  of  information  security  may 
generally  be  expressed  as  tne  problem  of  permittinc  the 
existence  of  only  tnose  access  relations  tnat  in  no  way 
violate  any  of  the  applicable  systems  policies. 

One  can  see  then,  tnat  tne  granularity  of  access  control 
within  a  system  is  dependent  upon  the  ability  to  distinguish 
attributes  of  subjects  and  objects  plus  tne  distinct  access 
modes  available.  The  primitive  access  modes  (l.e.,  tnose 
access  modes  tnat  are  not  decomposable  by  the  system) 
associated  with  the  design  of  the  system,  including  the 
protection  mecnanlsms,  designate  tne  associated  rlgnts 
accorded  to  an  access  request. 

When  tne  granularity  of  access  is  successively  refined, 
one  may  observe  two  conflicting  phenomena.  First,  the 
ability  to  distinguish  between  access  relations  is  more 
pronounced,  thus  allowing  for  greater  sophistication  and 
variety  in  policy  formulation.  The  problem,  however,  is  that 
tne  increased  distinctions  of  access  relations  increases  tne 
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complexity  of  tQc.  security  evaluation  process.  Systems 
designers  are  face!  wltn  tne  problem  of  striding  a  balance 
between  the  granularity  ot  access  and  the  complexity  of 
system  security  validation. 

This  nas  not  deterred  the  efforts  of  many  systems 
designers#  however,  as  tne  granularity  of  subjects  and 
objects  is  quite  refined  in  many  systems,  unfortunately, 
such  systems,  almost  without  exception,  nave  failed  to 
enforce  even  minimal  non-dlscretionary  security  policies. 

Two  generic  access  modes  are  particularly  useful  in  tne 
discussion  of  security.  These  are  Cl6j  "observe"  (the 
ability  to  observe  information)  and  "modify"  (tne  ability  to 
modify  information).  Other  access  modes  may  be  generally 
thought  of  as  a  finer  granularity  of  tnese  two  access  modes. 
Figure  3  Illustrates  one  sucn  possible  set  of  primitive 
access  modes  and  how  tney  are  associated  with  the  generic 
access  modes. 


Observe 


Modify 


Read  Execute  Wrl te  Append 


Figure  3.  Generic  Access  Modes 


The  problem  of  computer  security  enforcement  can  be 
reduced  to  the  problem  of  limiting  the  access  relations 
within  the  system  to  only  those  that  neither  directly  nor 


Inlirectly  violate  the  systems  security  policies.  If  one  can 
establish  that  all  of  the  access  relations  permitted  in  tne 
system  are  acceptable  to  the  policy,  one  has  established 
that  the  system  Is  "secure," 

F.  ILi.USTRATION  OF  POLICIES 

In  reviewing  tne  computer  science  literature,  tnls 
author  was  unable  to  discover  any  Illustration  forms 
appropriate  for  showing  tne  features  of  non-dlscretlonary 
security  policies  in  sufficient  detail  that  one  could 
readily  discern  all  permissible  access  relations  within  the 
system  simply  by  examining  tne  illustration  alone.  This 
section  presents  a  review  of  the  major  forms  examined  and 
their  failure  to  adequately  illustrate  access  relations.  It 
also  provides  two  proposed  alternative  forms  that  more 
clearly  illustrate  access  relations  of  a  system  In  a  manner 
which  leaves  no  doubt  as  to  the  nature  of  the  policy  and  tne 
requirements  for  its  enforcement. 


LOB 


Figure  4.  Basle  Lattice  Form 

Figure  4  shows  a  representation  for  a  lattice  structure 
commonly  found  in  matoematicai  texts  [22,23].  With  respect 


to  lattice  security  policies,  eacn  node  represents  an  access 
class  and  tne  arcs  slenify  tnat  tne  node  nearer  the  top  of 
tne  page  represents  an  access  class  wnicn  is  more  sensitive 
than  the  lower  nodes'  access  class.  Thus,  in  figure  4  one 
may  observe  tnat  A  >  D  and  B  w  A.  Sometimes  tnese  arcs  are 
labeled  by  ”>"  symbols,  but  tnis  merely  tends  to  clutter  tne 
illustration  and  provides  no  additional  information.  Note 
mat  this  form  provides  no  information  re^ardine  access 
relations  wltnout  some  examination  of  tne  policy  tnat  is 
being  illustrated,  e.g.,  one  cannot  readily  answer  tne 
question  "can  a  subject  of  access  class  A  write  to  an  object 
of  access  class  D?" 

The  form  shown  in  figure  5  [12,13J ,  provides  basically 
tne  same  information.  Tnis  form  Illustrates  tne  permissible 
information  flow  tnat  is  immediate  and  non-reflexive  by 
means  of  directed  arcs.  Nodes  are  once  again  used  to 
represent  access  classes.  Access  relations  are  still 
non-discerni bie  by  examination  of  tne  illustration  alone. 


Figure  5.  Information  Flow  Form 
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Anotner  form  w&lca  Is  popular  in  capabllity-oased 
protection  systems  researcn  [24 J ,  illustrated  in  figure  6, 
is  called  a  protection  grapn  [20j .  Tnese  grapns  specify  eacn 
subject  as  a  solid  node,  and  eacn  object  as  an  empty 
node,  "o”.  Tne  directed  arcs  between  nodes  specify  tne 
access  rients  of  tne  source  by  tne  associated  labels.  Tni= 
form  provides  an  extremely  detailed  means  of  representing 
all  access  relations  wltnin  tne  system.  Unfortunately,  tnis 
form  provides  such  detail  tnat  an  Illustration  of  any 
practical  system  becomes  exceedlnely  busy.  Thus  one  qulcJily 
loses  tne  ability  to  dlstingulsn  between  access  classes  even 
when  they  are  clearly  labeled.  What  is  needed  is  needed  is  a 
nlgner  order  of  abstraction  for  tne  presentation  of 
practical  systems. 


r,¥,a 
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An  access  relation  ^?rapn  clearly  snows  all  permissible 
access  relations  specified  by  a  non-discretlonary  security 
policy.  Reflexive  relations,  l.e.,  tnose  with  a  subject  of 
the  same  access  class  as  tne  object,  need  never  be 
specifically  cited  unless  all  access  modes  are  not  permitted 
wltnln  an  access  class.  Antisymmetric  relations  are  clearly 


defined 

by  the  directed  ar 

cs . 

Transitive 

relations  are 

Inferred 

from  tne  patn  of 

two 
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relations 
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of 
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access  class). 

Therefore,  tne  form  meets  the  mathematical  requirements  for 
a  lattice  in  that,  all  access  relations  for  the  lattice 
(l.e.,  a  universally  bounded  partially  ordered  set)  are 
clearly  illustrated. 

In  its  most  delineated  case,  tne  access  relation  graph 
is  reduced  to  a  protection  eraph.  The  advantage  of  the 
access  relation  graph  over  tne  protection  graph  is 
simplicity.  Only  tne  access  relations  needed  to  represent 
tne  policy  are  shown.  Additionally,  complex  policies  and 
composite  policies  are  illustrated  in  one  simplified  form. 

Another  illustration  form  that  is  particularly  useful 
when  discussing  uniform  lattice  structures  (i.e.,  tnose 
access  relation  graphs  where  tne  access  modes  between  any 
two  antisymmetric  access  classes  are  identical)  is  tne 
linear  access  eraph.  Such  a  graph  snows  tne  security 
label(s}  of  the  objects  (i.e.,  now  one  represents  tne 
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sensitivity  of  the  object)  and  denotes  tbe  access  modes 
available  to  subjects  of  varying  sensitivity  wltn  respect  to 
tne  sensitivity  of  tne  objects.  Figure  “(A)  Illustrates  a 
simple  general  linear  access  grapn.  In  tnis  figure,  subjects 
witn  greater  sensitivity  than  tne  objects  sensitivity  would 
enjoy  the  use  of  access  mode(s)  2  when  referencing  that 
object.  Subjects  of  inferior  sensitivity  than  the  objects 
sensitivity  would  enjoy  the  use  of  access  mode(s)  1  when 
referencing  that  object.  Subjects  of  tne  same  sensitivity  as 
the  Object  would  enjoy  access  modes  1  and  2  when  referencing 
the  Object.  The  linear  access  graph  for  tne  Multlcs  Ring 
Brackets,  first  pointed  out  to  the  author  by  R.  Schell,  is 
shown  as  an  example  of  a  familiar  policy  represented  in  this 
form  In  figure  8(B). 

_ _ access  mode(s)  1 _ 

System  [Security  System} 

I  High  _ Label  I  Low 

access  mode(s)  2 

(A) 
execute 

iRine  0  iRli  _ R3  ■ 

write  _ I  call  as  a  gate 

real 


(B) 

Figure  S.  Linear  Access  Graphs 
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Tne  dlsalvantage  of  tne  linear  access  grapn  is  mat  It 
may  only  be  used  for  Illustration  of  uniform  policies,  l.e., 
tnose  policies  wnere  tne  access  relations  between  any  two 
access  classes  (one  of  wnicn  is  more  sensitive  tnan  tne 
otner)  are  Identical.  Tne  succinct  nature  of  mis  form, 
however,  mates  it  possible  to  capture  tne  essence  of  a  class 
of  policies,  l.e.,  tnose  wnicn  may  be  described  by  tne  same 
linear  access  graph,  without  going  into  ail  the  details. 

G.  EXAMPLE  POLICIES 

Having  discussed  tne  nature  of  policies  in  general,  one 
is  now  prepared  to  examine  several  specific  policies  of 
Interest.  Sucn  a  discussion  logically  begins  with  tne  two 
broadest  classes  of  security  policies,  l.e.,  compromise  and 
subversion. 

Modify _ 

Upper  jSensltivlty  Lower  | 

I  Limits  _ Label  |  Limits 

Observe 

Figure  9.  Compromise  Policy. 

A  compromise  policy,  sometimes  referred  to  simply  as  a 
security  policy,  is  one  wnose  primary  Intent  is  to  proniblt 
the  unauthorized  observation  of  information.  Figure  9  show 
the  general  form  of  sucn  a  policy.  Subjects  may  observe  only 
tnose  objects  wnose  sensitivity  is  less  tnan  or  equal  to  tne 
subject's  sensitivity  in  order  to  prevent  direct  observation 


36 


of  an  object  by  an  unautnorized  subject,  viz.,  me  Simple 
Security  Condition  [10J .  In  order  to  prevent  Indirect 
observation  of  objects  by  unautnorlzed  subjects,  a 
sufficient  but  not  necessary  condition  establisnes  tnat 
modification  of  objects  must  at  least  be  limited  to  tnose 
subjects  wnose  sensitivity  is  less  tnan  or  equal  to  toe 
objects  sensitivity,  viz.,  tne  (Security)  Confinement 
Property  —  also  icnown  by  a  less  descriptive  title  as  tne 
^-Property  flii]  . 

A  subversion  policy,  sometimes  referred  to  simply  as  an 
integrity  policy,  is  tne  dual  of  a  compromise  policy.  Tne 
primary  Interest  of  a  subversion  policy  is  to  pronibit  tne 
unauthorized  modification  of  information.  Fleure  10 
illustrates  tnese  general  characteristics.  Subjects  may 
modify  only  tnose  objects  whose  sensitivity  is  less  than  or 
equal  to  tne  subject's  sensitivity  in  order  to  prevent 
direct  modification  of  an  object  by  an  unauthorized  subject, 
viz,,  tne  Simple  Integrity  Condition  [iilj  .  In  order  to 
prevent  indirect  modification  of  objects  by  unautnorlzed 
subjects,  a  sufficient  but  not  necessary  condition  is  that 
observation  of  objects  must  be  limited  to  tnose  subjects 
whose  sensitivity  is  less  than  or  equal  to  the  object's 
sensitivity,  viz.,  the  Integrity  Confinement  Property  [21J  . 


Fieure  l<8.  Subversion  Poiicy. 

Tne  Importance  of  subversion  policies  sQouid  not  te 
underestimated  [2,21j.  Chaa«in^  the  course  of  an  ICE'i,  for 
example,  saouid  in  most  cases  require  a  more  sensitive 
autnorlza tlon  tnan  simply  itnowing  its  course.  Sucn  policies, 
Qowever,  are  often  overlootced  in  many  Command,  Control,  and 
Communications  systems  [2J . 

Anotner  general  class  of  policies  tnat  is  of  general 
Interest  in  Security  Kernel  researcn,  and  waose  title  was 
coined  during  tne  course  of  tnls  researcn  effort  by  R. 
Scnell,  are  tne  "Program  Integrity”  policies  [4j .  Tne  notion 
of  program  integrity  stems  from  tne  desire  to  pronlblt 
unautnorized  modification  of  executable  programs  by  less 
trustwortny  subjects.  In  tne  general  case,  one  wlsnes  to 
ensure  tnat  tne  more  sensitive  programs  are  "tamperproof." 
In  otner  words,  one  wants  to  be  sure  tnat  me  program  can  ce 
"trusted"  to  perform  as  specified  and  cart  not  be  "trlcxed" 
by  merely  reading  data  of  lower  sensitivity  or  "importance." 
For  example,  a  system  designer/programmer  may  wlsn  to  Insure 
that  his  proerams  always  perform  as  specified  in  botn  nls 
test  environment  and  In  any  application  environment.  Onlixe 
a  strict  Integrity  policy  [21j  ,  program  integrity  is  not 
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concerned  wltd  tae  issue  of  general  o&servatlon  of 
information.  Froeram  iateifrlty  is  tnerefore  less 
conservative  (and  tnus  more  "rlsicy”)  tnan  Blbas  integrity 
policy.  Program  integrity  deals  only  witn  execution  and 
modification  of  information.  As  sucn,  figure  11  illustrates 
tae  general  form  of  a  program  integrity  policy. 


_ Execute 

Opper  (Sensitivity  Lower  1 

iLlmi  ts _  Label  1  Limits 

Modify 


Figure  11.  Program  Integrity  Policy. 


One  may  guarantee  tnat  no  direct  modification  of  a 
program  by  an  unautnorized  subject  (l.e..  a  direct  threat' 
is  possible  by  enforcement  of  tae  following  condition  : 


Simp],e  Program  Integrity  Coaditioa,  :  If  a  subject 
has  modify  access  to  an  object,  then  tne  program 
Integrity  of  the  subject  is  greater  tnan  or  equal 
to  tne  program  integrity  of  tne  object. 


Because  program  inte«rlty  policies  are  concerned  with 
tne  execution  issue  (versus  tne  observation  issue  [ZlJ  ) , 
Indirect  modification  of  information  is  not  strictly 
prottlblted.  Tnis  provides  a  certain  degree  of  flexibility, 
but  also  produces  a  certain  amount  of  ristc  tl9j  .  Confinement 
of  execution  reduces  tne  rlsx  of  sucn  an  indirect  tnreat  but 
does  not  eliminate  it.  A  more  sensitive  subject  must  be 
trusted  not  to  modify  a  less  sensitive  object  eitner 
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Intentionally  or  otnerwlse.  An  indirect  tnreat  occurs  wnen  a 


subject  executes  a  program  tnat  nas  been  modified  by  a  less 
trustwortny  subject,  tnerefore,  one  wisnes  to  confine  tne 
execution  access  relations.  Tbe  confinement  property  for 
program  integrity  is  defined  as  follows  : 


Program  Integrity  Conflnefnent  Property  ;  If  a 
subject  nas  execute  access  to  an  object,  tnen  tne 
program  integrity  of  tne  object  is  greater  tnan  or 
equal  to  tne  program  integrity  of  tbe  subject. 


Tne  remainder  of  tne  section  discusses  tnree  policies  of 
general  Interest  to  federal  aDP  users.  Any  computer  system 
designed  for  use  by  tne  federal  government,  snould  as  a 
minimum,  consider  its  ability  to  enforce  these  policies. 

1 .  National  Security  Policy 

The  National  Security  Policy  classifies  information 
essential  to  tne  National  Defense  or  foreign  relations  of 
the  United  States.  The  President  of  tne  United  States 
establisned  this  policy  in  Executive  Order  Number  12065 
dated  June  2S,  1975  125].  This  order  defines  three  levels  of 
classification  as  follows  : 


TOP  SECRET  :  That  information  or  material  the 
unautnorlzed  disclosure  of  which  could  reasonably 
be  expected  to  cause  exceptionally  grave  damage  to 
the  national  security. 

SECRET  :  Tnat  information  or  material  tne 
unauthorized  disclosure  of  which  could  reasonably 
be  expected  to  cause  serious  damage  to  the 
national  security. 
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CONFIDENTIAL  ;  Ttiat  informailon  or  naterial  tne 
unautaorlzei  llsclosure  of  wnicn  could  reasonably 
be  expected  to  cause  da:nage  to  tne  national 
security. 

Inpliclt  in  tnis  set  of  definitions,  tnere  also 
exists  a  classification  of  information  wnicii  is  not 
classified.  Taerefore,  one  nas  four  nierarcnlcal  access 
classes  establlsned  by  tnis  policy,  tne  intent  of  wnicn  is 
to  prevent  unautnorized  disclosure  (viz.,  observation)  of 
information  so  classified.  Figure  sftows  tfte  access 
relation  grapn  for  tnis  compromise  policy  wnicn  is  referred 
to  as  tne  basic  National  Security  Policy. 

Executive  Order  12065  also  establlsnes  [25J  tne 
autnority  to  originally  classify  new  information. 
Information  may  be  classified  Top  Secret  only  by  officials 
designated  in  writing.  Information  may  be  classified  Secret 
only  by  officials  wno  nave  Top  Secret  classifications  or  oy 
officials  designated  in  writing.  Information  may  be 
classified  Confidential  only  by  officials  wltn  Top  Secret  or 
Secret  classifications  or  by  officials  designated  in 
writing. 

In  order  to  obtain  access  to  classified  material, 
the  order  Indicates  that  a  person  must  be  determined 
trustwortny  (granted  clearance)  and  tnat  access  is  necessary 


in  the  performance  of  tnat 

persons' 

duties  ("need 

to  icnow" 

). 

This  is 

a  discretionary 

policy. 

nowever,  and 

will 

be 

discussed 

no  furtner.  All  classified  material 

shall 

be 
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appropriately  and  conspicuously  marlted  to  put  all  persons  on 
clear  notice  tnat  tne  Infor^iatlon  Is  classified.  Classified 


material  no  longer  needed  shall  be  promptly  destroyed. 


Figure  12.  Basic  National  Security  Policy. 

2.  National  Integrity  Policy 

Tne  dual  of  tne  National  Security  Policy  Is  tne 
National  Integrity  Policy  [21j.  Motivation  for  sucn  a  policy 
comes  from  tne  desire  to  pronltlt  subversion,  l.e.,  tne 
unautnorlzel  modification  of  Information.  The  following  set 
of  Integrity  classes  nave  been  esiabllsned  for  tnls  policy 
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[21],  Implicit  wltti  this  classification  scheme,  one  also  nas 
Information  that  is  not  classified. 

TOP  SECRET  :  That  information  or  material  the 
unauthorized  modification  of  which  could 
reasonably  be  expected  to  cause  exceptionally 
grave  damage  to  the  national  security. 

SECRET  :  That  information  or  material  the 
unautnorized  modlf icatlon  of  wnicn  could 
reasonably  be  expected  to  cause  serious  damage  to 
the  national  security. 

CONFIDENTIAL  :  That  information  or  material  tne 
unauthorized  modification  of  which  could 
reasonably  be  expected  to  cause  damage  to  the 
national  security. 

One  further  point  coacernin^  Intesriiy  Policies  must 
be  emphasized  before  one  proceeds.  Senerally  speaxlng,  one 
has  a  ffood  notion  of  how  to  classify  information  with 
respect  to  security  and  unauthorized  observation,  but 
classification  with  respect  to  integrity  is  not  so  easily 
identified.  In  some  sense,  integrity  classification  must  be 
determined  by  the  object's  potential  Importance  rather  than 
by  its  current  Importance.  Consider,  for  example,  a  simple 
sine  function  tucAed  away  in  some  obscure  user  library.  If 
tnis  function  is  used  to  compute  trajectories  for  an 
inter-continental  ballistic  missile,  it  becomes  TOP  SECRET 
wltn  respect  to  tne  National  Integrity  Policy,  whereas,  it 
Is  clearly  UNCLASSIFIED  with  respect  to  the  National 
Security  Policy.  Classification  of  Information  wltn  respect 


43 


to  Integrity  will  generally  require  considerable  planning 
and  foreslgnt  [2J . 


3.  Prlvacj 


Tne  Code  of  Fair  Infor'nation  Practices  and  tne 


Privacy  Act  of  1974  estabiisned  the  following  basic  policy 
for  the  Federal  Government  [26J . 


(1)  There  must  be  no  personal  data  record-xeeping 
systems  wnose  very  existence  is  secret. 

(2)  There  must  be  a  way  for  an  individual  to  find 
out  what  Information  about  him  is  on  record  and 
now  it  is  used. 

(3)  There  must  be  a  way  for  an  individual  to 
correct  or  ammend  a  record  of  Identifiable 
information  about  nlm. 

(4)  There  must  be  a  way  for  an  individual  to 
prevent  information  about  him  that  obtained  for 
one  purpose,  from  being  used  or  made  available  for 
other  purposes  witnout  nls  consent. 

(5)  Any  organization  creating,  maintaining,  using 
or  disseminating  records  of  identifiable  personal 
data  must  guarantee  tne  reilaoillty  of  the  data 
for  their  Intended  use  and  must  tax®  precautions 
to  prevent  misuse. 


All  information  systems  (including  computer  systems) 
used  by  tne  Federal  Government  are  subject  to  tnese  privacy 
requirements  and  must  incorporate  a  corresponding  set  of 
safeguards  wnen  tne  process  "Privacy  Information." 

These  three  policies  are  applicable  to  many  Federal 
data  processing  applications.  Numerous  other 
non-dlscretlonary  policies  exist  botn  in  tne  Federal,  State, 
and  Local  governments  and  In  private  Industry.  It  nas  been 
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shown  in  this  section  that  these  policies  may  be  precisely 
desclbed  using  access  relation  grapns  or  linear  access 
graphs  as  described  In  this  section.  Once  a  policy  has  been 
so  described,  a  precise  evaluation  of  Its  enforcement  may  be 


III.  A  FORMALIZED  NOTION  OF  DOMAINS 


The  notion  of  a  "domain"  has  not  been  clearly  presented 
In  a  precise  manner,  nor  properly  defined.  Dennis  fSJ 
Introduced  the  concept  by  describing  a  "sphere  of 

protection."  Lampson  [6J  refined  tne  concept,  coining  me 
term  "domain",  and  defined  a  domain  as  a  ^roup  of 
capabilities  or  protected  names.  Scnroeder  [3J  maintains 

Lampson's  definition,  but  provides  an  in-depth  discussion 
and  presentation  of  nls  Ideas,  many  of  wnicn  were 
instrumental  in  the  formulation  of  tne  concepts  presented 
nere.  Scnroeder  further  refined  the  ideas  from  nls  tnesls, 
and  together  with  Saltzer  [l4j,  defines  a  domain  as  a  set  of 
objects  that  may  be  accessed  by  a  principal.  This  definition 
Is  the  most  commonly  accepted  today,  but  for  any  rigorous 
discussion  of  domains,  or  for  presentation  of  a  concept  such 
as  the  assignment  technique,  a  more  formalized  definition  is 
needed . 

An  access  domain  A,  Is  a  tuple,  (a^,  a^t  .••,  ,  .... 

a^  ),  where  n  Is  the  number  of  primitive  ( non-decomposable ) 

access  modes  in  the  system  and  a^  is  tne  set  of  all  objects, 

i  0,,  0_,  0  .  ,  ...,  0  t,  accessible  by  the  "I’th 

12  j  m 

access  mode.  An  (access  mode)-domain  is  the  set  of  objects 
that  a  process  executing  in  that  domain  (l.e.,  a  subject) 
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has  the  rlehtt  or  privilege  oft  accessin<?  according  to  the 
rules  for  that  particular  access  mode. 

Consider  the  following  examples  of  domains: 

A^:  (Observe(O)  :tA.}  ,  Modify (M) : {B}  ) 

(0:{A,B,C},  M:{A.B,C}  ) 

A^:  (0:{A,C.D},  M:t;3}  ) 

A^:  (0:{A,B,CtDi,  M:{A,B,CtDi  ) 

The  ohserve-domaln  of  A^^  (denoted  as  OA^^  )  is  object  A 
and  the  modlfy-domaln  MAj^  Is  object  B.  Note  that  simply 
referring  to  as  containing  objects  A  and  B  would  not 
provide  much  Insight  into  the  true  nature  of  this  domain 
[1«1. 

The  notion  of  "dominance"  with  respect  to  domains  was 
introduced  by  Srohn  [16] .  These  notions  are  refined  from 
security  dominance  and  Integrity  dominance  to  a  more  general 
definition  of  dominance. 

A  domain,  dominates  ( )  Aj  If  and  only  If  (iff) 

for  each  access  mode  "a",  aAj  ^  aA^.  This  is 

particularly  useful  wnen  discussing  tne  relationship 
between  domains  with  respect  to  access  modes.  One  can  say 
tnat  for  some  aj^,  aj^A^  ^  a^^A^  Iff  aj^A^  ^  a^^A^. 

Continuing  with  the  previous  group  of  example  domains, 

OA4  OA3.  OA3  •<  OA3.  MA4  ^  MA3,  MAj_  MA3.  A^ 
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fill 


similar  examples 


but  does  not  dominate  a^^  . 
can  be  formulated  by  tbe  reader. 

Dominance  domains  may  be  labeled  for  convenience.  In  tne 
Multlcs  system,  for  example,  the  dominance  domains 
established  by  tne  ring  mecnanlsm  were  xnown  as  rings  and 
were  labeled  by  ring  numbers.  Scnroeder's  protection 
mechanism  also  uses  numbers  as  labels  for  dominance  domains 
[8J. 

The  systems  protection  mechanisms  establish  a  set  of 
dominance  domains  that  can  be  used  for  evaluating  tne 
protection  mechanisms.  These  dominance  domains  dominate  all 
domains  that  currently  exist  or  may  exist  wltnln  the  system. 
If  one  can  establish  the  set  of  dominance  domains  for  the 
system  and  one  can  snow  that  the  policy  noils  for  these 
domains,  then  one  can  snow  that  the  policy  holds  for  all 
domains . 

A  mechanism.  In  the  most  general  sense,  is  something 
that  prevents  the  occurrence  of  certain  sequences  of 
operations  [15].  A  protection  mechanism,  or  an  access 
control  mecnanlsm,  can  oe  defined  as  something  that  prevents 
the  unauthorized  access  of  Information.  In  the  broadest 
sense,  one  may  include  as  protection  mechanisms  such  things 
as  vails,  patrol  dogs  and  cypher  locics.  More  specifically, 
though,  a  protection  mecnanlsm  for  a  computer  operating 
system  Is  a  procedure.  Implemented  in  software,  firmware  (if 
there  Is  such  a  thing)  or  hardware,  that  prohibits  tne 


access  of  objects  witain  a  system  such  t&at  the  domain  of 
any  process  is  dominated  oy  some  particular  dominance  domain 
Inherently  established  by  the  protection  mechanisms. 


Figure  13.  Multics  Rings 

The  Multics  Ring  Mechanism  [2BJ  is  a  well  tnown 
protection  mechanism  that  provides  an  excellent  example  for 
the  discussion  of  dominance  domains.  One  may  tnlnit  of  these 
dominance  domains  as  a  set  of  concentric  rings  (Illustrated 
in  figure  13),  each  numbered  in  increasing  order  from  tie 
Inner-most  ring  op  wrnei.  The  Kernel  is  conventionally 
assigned  ring  number  zero. 


The  'iultlcs  Rlne  Mechanism  determines  the  authorized 
access  of  a  subject  b7  means  of  tae  current  rln#r  number  (r) 
that  specifies  the  dominance  domain.  Discrimination  amon? 
objects  is  by  means  of  a  rln?  bracset.  Tne  rln^  bracnet  is  a 
three-tuple  (Rl,  H2,  R3)  where  HI#  32,  and  R3  are  rln« 
numbers  and  Rl  must  be  numerically  less  tnan  or  equal  to  R2 
which  is  less  than  or  equal  to  R3.  Access  is  characterized 
by  tne  rules  illustrated  in  tne  linear  access  grapn  snown  in 
figure  14. 


Execute  Call 

I  iRing  0 _ _ _  iHi  ^  ' 

I  Wri te  (Modify) 

Read  (Observe) 


(as  a  gate) 
- 


Figure  14.  Multlcs  Ring  Mechanism  Linear  Access  Grapn 

Consider  now  a  system  that  uses  tne  Muitics  Ring 
Mechanism  and  discriminates  among  four  distinct  hierarchical 
rings  (0  tnru  3).  One  may  tninic  of  tne  domains  estabilsned 
by  this  system  as  Ag  ,  A^^ ,  A2 ,  and  A^ .  Consider  tne 

rules  of  access  established  in  figure  14,  waere  MAg  is  tne 
objects  that  may  be  modified  by  a  process  in  domain  0.  Then 

MAg  0-6  mAj^  MA2  -c  MA3  .  Likewise,  OAg  «sc  OA^^ 

OA2  ^  OA^ .  No  such  relationship  exists  for  execute  or 
call  (as  a  gate).  EA^  does  not  ^2*  ^ 

some  object  I,  In  which  case  X  €  EA2  but  X  1^2* 

Likewise  CA^  (the  Call  (as  a  gate)  domain  of  A^  )  does  not 

^  CA2  as  R3  may  be  zero,  for  example,  in  which  case,  Rl 
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ani  R2  must  be  zero,  ruling  out  tne  possibility  of 
successive  lomlnance  call-lomains. 

Note  tnat  a  single  object  may  be  a  member  of  several 
dominance  domains.  Some  object  X,  with  rine  bracKets 
is  a  member  of  OAq  ,  OAj^,  3A2.  MAq  ,  Eaq  ,  SAj^  ,  EA2 .  ana 
CA3.  Therefore,  X  €  Ag,  Aj^,  and  a^*  T^is  concept 

can  be  confusing  as  an  object  Is  a  distinct  entity  generally 
represented  by  a  single  Imaee. 

Tnls  section  nas  established  a  formal  definition  of 
domains  suitable  for  discussion  of  complex  domain  related 
Issues.  Tne  notion  of  dominance  domains  was  Introduced  and 
their  relationship  to  protection  mechanisms  established.  The 
Multlcs  Ring  Mechanism  provided  an  example  of  tne  means  by 
which  one  may  evaluate  tne  dominance  domains  established  by 
a  protection  mechanism.  Ravine  formulaized  these  concepts, 
the  relationship  between  policy  and  mechanism  may  now  be 
investieated  in  an  oreanized  manner. 
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17.  THE  ASSIGNMENT  TECHNIQUE 


This  section  Introduces  a  mathematical  frameworJt  for 
evaluating  the  relationship  between  non-dl scretlonary 
security  policies  and  protection  mecnanisms .  An  evaluation 
approach,  termed  "Tne  Assignment  Tecnnlque",  utilizes  tne 
entity  -  relationship  model  in  establishing  an  assignment 
between  the  security  classes  of  information  establlsnea  by 
the  policy  constraints,  and  dominance  domains,  established 
by  the  properties  of  tne  mecnanism.  Tne  assignment  technique 
provides  a  theoretical  foundation  for  assessing  the 
sufficiency  of  an  access  control  mecnanism  with  respect  to  a 
well  formed  protection  policy. 

This  section  begins  with  a  general  discussion  of  tne 
meaning  of  "assignment".  It  then  proceeds  to  Introduce  the 
assignment  tecnnlque  In  a  general  form.  The  section 
concludes  with  a  simplification  of  tne  assignment  technique 
male  possible  by  tne  lattice  nature  of  non-dlscretlonary 
security  policies. 

A.  ASSIGNMENT 

Assignment  Is  the  establishment  of  a  relationship 
between  two  entitles  such  that  tne  first  entity  Is  "assigned 
to"  tne  second  entity.  Mathematically,  tne  term  assignment 
Is  not  significant.  One  could  easily  have  said  that  entity  1 
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Is  related  to  entity  2.  Intuitively,  nowever,  assignment  is 
associated  wltn  tne  connotation  ”to  fix  autnorltati veiy". 
This  precisely  describes  the  manner  in  which  tnis 
relationship  is  estabilsned. 

Assignment  may  be  denoted  oy  a  graph  from  the  first 
entity  to  the  second  as  follows: 


is  assigned  to” 

It  is  important  to  recognize  that  assignment  does  not 
alter  either  entity.  Assignment  is  merely  the  act  of 
associating  an  entity  or  set  of  entitles  with  some  other 
entity  or  set  of  entities. 

Another  way  to  describe  assignment  Is  In  terms  of  tne 
act  of  forming  a  tuple  (entity  1,  entity  2).  Additionally, 
one  may  tnlnt  of  assignment  as  a  function  (l.e.,  "is 
assigned  to”)  where  the  assignment  process  establishes  a 
mapping  between  two  otherwise  disjoint  entities.  Regardless 
of  the  context  of  discussion  or  the  symbolism  used,  one  may 
simply  taint  of  assignment  as  tne  act  of  associating  one 
thing  with  another. 

B.  THE  TECHNIQUE 

The  essence  of  the  assignment  technique  Is  relatively 
simple.  First  of  all,  consider  the  nature  of  a  lattice 
security  policy.  Such  a  policy  partitions  tne  objects  of  a 
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system  into  a  lattice  of  equivalence  classes  labeled  by  ttie 
access  classes  as  discussed  in  section  II.  Eacn  equivalence 
class  can  be  thougnt  of  as  an  entity  tfiat  may  be  subject  to 
assignment. 

Then  consider  a  mechanism,  which  establishes  a  lattice 
of  dominance  domains  as  discussed  in  section  III.  Each  of 
these  domains  can  also  be  thought  of  as  an  entity  that  may 
be  subject  to  assl^hment. 

Since  an  assignment  can  be  established  between  any  two 
entities,  one  can  ma*e  an  assignment  between  the  equivalence 
classes  established  oy  a  lattice  security  policy  aud  tne 
dominance  domains  established  by  some  protection  mecnaalsm. 
One  may  then  validate  that  (for  this  assignment^  tne 
mechanism  is  sufficient  to  support  this  policy.  This 
validation  is  made  by  examining  tne  set  of  access  relations 
that  the  mechanism  permits,  and  testing  for  possible 
violations  of  the  policy. 

Tne  assignment  tecnnlque  can  be  described  more 
systematically  as  follows; 

1)  Determine  if  tne  policy  is  a  lattice 
policy.  If  not,  the  assignment  technique  does  not 
apply. 

2)  Establish  tne  set  of  equivalence  classes, 

{  e^ ,  C2  *  •  •  •  t  e]^  f  •  •  •  *  Sp  J ,  that  are 

associated  with  each  access  class. 

3)  Determine  the  set  of  dominance  domains, 

{  ^1 ,  ^2  •  •  •  • f  ♦  • • • f  } »  tha  t  are 

established  by  the  systems  protection  mechanism. 
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4)  Make  an  assignment  from  e,^  to  A^. 

5)  For  tnis  assl<rnment,  examine  tne  access 
relations  permlttea  by  tne  mecnanism,  testing  for 
possible  violations  of  tne  policy. 

6)  If  no  violations  can  exist,  tne  mecnanism 
is  sufficient  for  tne  policy  In  question. 

Step  4  of  tne  assignment  metnoa  allows  for  considerable 
flexibility  in  tne  manner  in  wnlcn  assignments  can  be  made. 
Any  possible  mapping  from  equivalence  classes  to  dominance 
domains  may  be  considered.  Tnls  fleilblllty,  nowever, 
Implies  considerable  effort  in  order  to  determine  tnat  a 
mechanism  Is  not  sufficient  for  a  given  policy.  Fortunately, 
in  tnis  tnesls  one  is  specifically  dealing  witn  tne  security 
issue.  Because  of  this,  several  refinements  can  be  made  tnat 
greatly  simplify  tnis  task. 

C.  SIMPLB  ASSIGNMENT 

The  question  of  how  one  cnooses  to  make  assignments 
(l.e.,  tne  cnolce  of  an  assignment  scneme)  may  seem 
relatively  complex  upon  first  inspection  of  tne  assignment 
tecnnlque.  Tne  problem,  nowever,  becomes  almost  trivial  wnen 
dealing  wltn  simple  non-discretionary  security  policies  as 
Is  hown  by  the  following  arguments. 

First  of  ail.  It  Is  clear  tnat  tne  equivalence  classes 
(established  by  the  policy  constraints)  represent  distinct 
access  classes.  It  Is  also  clear  tnat  tne  dominance  domains 
represent  distinct  sets  of  objects.  If  more  than  one 
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equivalence  class  were  assigned  to  tne  same  dominance 
domain,  taen  taere  is  notning  in  tne  mecnanlsm  to 
dlstlnguisn  between  tne  access  classes.  But  tne  policy  does 
draw  some  distinctions  between  tnese  access  classes  (l.e., 
tnat  distinction  establlsned  by  tne  definition  of  tne  access 
classes),  so  it  would  not  be  possible  to  enforce  tne  policy 
with  such  an  assignment.  All  such  assignments  ran  be 
eliminated,  a  priori. 

On  the  other  hand,  if  one  equivalence  class  was  assigned 
to  more  tnan  one  dominance  domain,  tnen  some  distinction  is 
bein«  made  for  an  access  class  that  is  not  specified  in  tne 
policy.  In  some  cases,  one  may  find  that  sucn  distinctions 
produce  violations  of  the  policy.  Altnoueh  other  cases  may 
not  do  so,  tnese  extra  dominance  domains  are  unnecessary, 
providing  distinctions  whicn  nave  no  slenif icance . 
Tnerefore,  tne  number  of  dominance  domains  of  interest 
established  by  tne  mechanisms  should  be  equal  to  the  number 
of  access  classes  established  by  the  policies. 

One  may  attempt  to  argue  tnat  there  may  exist  dominance 
domains  that  do  not  receive  an  assignment.  Such  domains, 
however,  must  be  either  empty  or  in  no  way  allow  for  an 
exception  to  the  enforcement  of  tne  policy.  As  sucn,  one 
need  not  be  concerned  with  tne  question  of  tneir  existence. 
One  need  only  concentrate  on  the  dominance  domains  for  which 
the  assignment  was  made. 
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Conslderlne  assienment  as  a  function.  It  has  been 
establlsned  tnat  tne  only  assignment  scnemes  of  Interest  are 
bijectlve  (l.e.,  a  one  to  one  and  onto  relatlonsnip  between 
tne  access  classes  and  tne  dominance  domains  122] ).  This 
provides  some  Improvement,  but  one  is  still  faced  with  at 
least  pf  possible  assignment  schemes  to  evaluate  (where  p  is 
tne  number  of  access  classes  establlsned  oy  tne  policy). 

One  may  eain  considerable  improvement,  however,  by  only 
attempting  to  validate  one  simple  mechanism  wltn  respect  to 
one  simple  policy  at  a  time.  Furthermore,  the  icnowledee  of 
partially  ordered  sets  may  be  used  to  maite  our  assignments 
la  a  very  selective  manner.  This  is  done  by  first  requiring 
tnat  tne  lattice  for  tne  dominance  domains  of  Interest  tnat 
one  considers  for  assignment,  be  an  isomorphic  Image  of  that 
for  the  equivalence  classes.  This  may  not  be  a  necessary 
condition,  however,  it  In  no  way  Invalidates  the  results 
shown  (as  one  would  otherwise  be  dealing  with  an  isomorphic 
sub-image  establlsned  by  tne  mecnanl sm ) ,  and  It  is  nelpful 
in  this  discussion. 

ifhen  considering  tne  isomorphic  image  of  a  lattice,  the 
problem  of  assignment  is  reduced  to  a  question  of 
orientation.  One  may  either  assign  the  greatest  lower  bound 
of  tne  lattice  to  tne  greatest  lower  bound  of  tne  image,  or 
assign  the  greatest  lover  bound  of  the  lattice  to  the  least 
upper  bound  of  tne  image.  Any  other  assignment  would  not  te 
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acceptable  as  it  would  violate  the  ordering  of  the  lattice 
or  of  the  image. 

So  for  a  system  of  "ic”  isomorphic  images  of  the  lattice 
established  by  the  policy,  one  need  only  consider  at  most, 
21c  assignment  schemes.  In  most  practical  cases,  when  tne 
mechanism  establishes  isomorphic  imaees  which  are  identical 
in  their  access  control  properties  because  of  tne  uniform 
nature  of  the  mechanism,  one  need  consider  only  2  assignment 
schemes. 

The  Simple  Assignment  Theorem  :  For  any  simple 
lattice  policy  and  an  isomorphic  image  established 
by  some  protection  mechanism,  no  more  than  two 
assignment  schemes  are  necessary  to  validate  the 
sufficiency  of  tne  mechanism  to  enforce  tne 
policy. 

Proof  Sketch  :  Tne  proof  proceeds  by  snowing 
that  two  assignment  schemes  are  reasonable  and 
that  all  others  are  not. 

1)  Mage  assignments  starting  from  tne  greatest 
lower  bound  (GLB)  of  the  lattice  to  the  GLB  of  the 
isomorpnlc  image.  Then  assign  every  reachable 
access  class  (l.e.,  tnose  of  unit  distance)  to  a 
reachable  dominance  domain  in  the  isomorphic 
image.  Next  assign  all  reachable  access  classes 
from  those  Just  assigned  (which  are  not  already 
assigned)  to  a  corresponding  reachable  dominance 
domain.  Proceed  in  this  fashion  until  all  access 
classes  have  been  assigned.  An  assignment  sucn  as 
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tnat  snown  in  figure  15  will  result,  v*nere  me  L'JE 
is  assigned  to  me  LUB,  A  is  asslened  to  a',  E  is 
assigned  to  B',  and  so  t'orta. 

Tnis  assignment  is  a  valid  asslenmeni  in  mat 
an  assignment  can  be  -nade  from  me  access  classes 
to  tne  dominance  domains  mat  is  not  inaerently 
incorrect  and  merefore  is  wormy  of 
consideration.  Tnis  does  not  mean  tnat  tne 
protection  mecbanism  is  sufficient  for  tnis 
assignment.  It  only  implies  tnat  sucn  an 
assignment  scneme  is  wortny  of  consideration. 


ACCESS  classes  DOMINANCE  DOMAINS 


Z)  Now  consider  a  second  practical  assignment. 
This  assignment  starts  from  tne  3LB  of  tne  lattice 
malting  an  assignment  to  tne  LDB  of  tne  Isomorpnic 
image  and  proceeding  as  in  me  first  assignment 
scneme.  Tne  resultlne  assignment  is  illustrated  in 
figure  16  vnere  tne  LOB  is  assigned  to  me  GLE,  A 
is  assigned  to  D',  D  Is  assigned  to  A',  and  so 
fortn. 
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ACCiISS  CLASSLS  DOMINANCE  DOMAINS 


It  Is  important  to  note  tnat  if  tns  lattice 
structure  is  not  uniform,  i.e.,  inverting  me 
lattice  rfouil  not  pronuce  me  same  lma<?e,  men 
only  one  of  tiie  two  aforementioned  assignment 
scnemes  will  ce  successful.  Tnis  limitation  occurs 
because  one  encounters  some  set  of  reaciiable 
access  classes  during  assignment  tnat  nave  no 
corresponding  reacnable  dominance  domains. 
However,  for  any  lattice  structure,  uniform  or 
otnerwlse,  tnere  win  always  be  one  assignment 
scneme  to  an  Isomorpnic  image  tnat  is  wortny  of 
consideration.  Tnls  leads  us  to  tne  following 
corollary. 

porollary  1.  For  any  lattice  policy  ana 
an  Isomorpnic  Ima^e  estabiisned  by  some 
protection  mecnanlsm,  tnere  exists  at 
least  one  valid  assignment  scneme. 

Proof  SAetcn  (Corollary  1)  :  Tne  proof 
is  trivial  from  tne  de^nitlon  of  an 
Isomorpnic  Imaffe.  If  a  lattice  nas  an 
isomorpnic  image,  tnen  at  least  one 
ordering  of  nodes  in  tne  image  is 
identical  to  tne  ordering  of  nodes  in 
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lae  lattice,  tnerefore,  tals  ordering  is 
wortny  of  consideration. 

3)  Now  consider  tne  assienment  of  tne  GI£ 


access  class  to  any  doTilnance  domain  otner  than 
tne  LUB  or  tne  GLB.  It  tnis  is  lone,  tnen  some 
otner  access  class  must  oe  assigned  to  tne  LDB 
dominance  domain  and  still  anotner  access  class 
must  oe  assigned  to  tne  GLB  dominance  domain.  But 
if  tne  isomorpnic  image  is  to  maintain  tne 
ordering  of  tne  access  classes,  tnen  tnere  exists 
some  ordering  wnicn  is  not  valid  oecause  eitner 
tne  GLB  or  tne  LGB  of  tne  isomorpnic  image  is  to 
be  considered  less  tnan  tne  GLB  (in  tne  image) 
wnicn  must  be  tne  least  element  (viz.,  least 
sensitive)  according  to  tne  policy.  Therefore, 
sucn  an  assignment  can  never  be  valid.  Tnus  one  is 
reduced  to  tne  taslc  of  considering  only  two 
possible  assignment  schemes  of  interest. 

One  can  further  simplify  tne  assignment  lecnnique  by 
combining  steps  4  and  b.  This  is  accomplished  by  matting,  an 
assignment  and  examining  all  access  relations  producible 
Immediantly.  If  an  access  relation  Is  not  valid,  one  can 
quickly  determine  that  toe  assignment  scheme  in  use  will  not 
validate  the  sufficiency  of  the  mechanism. 

When  one  is  dealing  with  more  complex  lattice 
structures,  one  is  faced  with  two  alternatives.  One  can 
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eitner  vailiate  tne  sufficiency  of  tne  necnanlsm  for  eacn 
sub-policy*  establlsning  tnat  if  eacn  sufc-pollcy  is 
enforced,  then  the  complex  policy  is  enforced,  or  one  may 
Choose  to  validate  tne  complex  policy  by  a  straight  forward 
assignment.  rfhen  using  a  straight  forward  assignment 
approacn,  one  must  remember  that  tne  Simple  Assignment 
Theorem  may  not  apply.  This  is  of  no  particular  consequen''® 
when  validating  a  protection  mecnanlsm  designed  for  a 
particular  policy  where  the  assignments  are  chosen 
carefully.  However,  establishing  the  insufficiency  of  an 
arbitrary  mecnanism  may  require  considerably  more  effort. 

The  basic  principles  associated  with  the  assignment 
technique  nave  been  presented  in  this  section.  One  may  now 
consider  some  simple  examples  tnat  illustrate  tne  usefulness 
of  assignment. 
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V.  '1ECHANISM  SUTFICIENCI  VALIDATION  BT  ASSIGNMENT 


One  of  tae  most  practical  uses  for  tne  assignment 
tecnnlque  Is  sufficiency  validation  of  protection  mecnanisms 
(l.e.,  validation  of  tneir  ability  to  enforce  security 
policies)  [4j .  In  contrast  to  other  validation  techniques 
[ll,17j,  tne  assignment  technique  presents  a  method  whose 
mathematical  model  (l.e.,  the  entity-relationship  model)  is 
based  upon  the  nature  of  security  itself,  rather  tnan  other 
methods  which  adapt  the  nature  of  security  into  a  form 
designed  to  mesh  with  tne  prescribed  format  of  some  well 
Known  mathematical  model.  This  section  discusses  mechanism 
sufficiency  validation  by  assignment  for  several  well  Known 
linear  non-dlscretionary  security  policies.  Althoueh  the 
principles  discussed  in  this  section  apply  for  all  lattice 
security  policies,  only  linear  lattice  poli'^les  are 
discussed  in  this  section  as  tney  provide  a  sufficient 
foundation  for  me  discussion  of  any  lattice  policy  and  are 
more  clearly  illustrated  in  this  context. 

A.  MDLTICS  RING  MECHANISM  ASSIGNMENTS 

The  question  of  tne  sufficiency  of  tne  Multlcs  Ring 
Mechanism  for  enforcement  of  the  basic  National  Security 
policy  was  tne  initial  problem  tnat  prompted  tne  current 
research  effort  and  led  to  the  formulation  of  tne  assignment 
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technique.  It  is  appropriate  then,  that  this  analysis  be 
presented  as  an  Introductory  application  of  simple 
assignment. 


1.  Compromise  Policy 

As  stated  previously  in  section  II,  the  basic 
National  Security  policy  is  a  simple  lattice  security 
policy.  Figure  13  illustrates  tnls  policy. 

The  dominance  domains  of  the  l^ultics  Ring  Mechanism 
are  most  frequently  shown  as  concentric  rings  numbered  in 
Inereaslnr  Integer  order  from  the  Innermost  rlni;  or  the 
kernel.  The  security  kernel  is  generally  assigned  ring 
number  0.  For  simplicity,  only  a  system  with  rings  0  thru  3 
Is  shown  in  this  analysis.  Assignment  to  other  ring  numbers 
(such  as  2  thru  5  or  4  thru  7)  will  produce  similar  results 
because  of  the  uniform  nature  of  the  Multlcs  Ring  Mechanism. 

Consider  as  the  first  assignment  scheme,  the 
assignment  of  the  TOP  SECRET  access  class  (the  least  upper 
bound  of  the  policy)  to  ring  0  (the  least  upper  bound  of  tae 
dominance  domains).  The  assignment  produced  is  illustrated 
in  figure  17. 

Next,  according  the  assignment  technique,  one  must 
examine  the  access  relations  permitted  by  the  mechanism  and 
test  for  possible  violations  of  the  policy.  In  order  to  do 
so,  one  must  first  examine  the  nature  of  the  Multics  Ring 
Mechanism  more  closely.  A  detailed  discussion  Is  given  by 
Schroeder  C27J ,  however,  a  simple  explanation  of  the 


pertinent  details  as  used  In  this  discussion  is  provided  for 


taose  readers  not  otaerwise  familiar  wiia  Multics. 


Observe} 


is  assigned  to’ 


s  assigned  to 


Observe} 


is  assigned  to 


Observe} 


is  assigned  to 


f  Rini?  0  J 


Ring  1 


Ring  2 


Ring  3 


Figure  17,  Basic  National  Security  Assignment  1. 


Tae  Multics  Ring  Mecnanlsm  determines  tne  autnorized 
access  of  a  process  by  means  of  the  current  ring  number  ( r) . 
Tnus  a  process  vnica  is  executing  in  ring  number  1  would 
need  to  be  cleared  for  at  least  SECRET  information  according 
to  tais  assignment  scneme. 

The  Multics  Ring  Mechanism  discriminates  among 
objects  by  means  of  a  ring  bracket.  The  ring  bracket  is  a 
three-tuple  (  Rl,  R2,  R3)  where  Rl,  R2  and  R3  are  ring 
numbers  and  Rl  j^H2  1.R3.  Access  to  objects  is  restricted 
such  that  the  current  ring  of  execution  must  he  less  than  or 
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equal  to  R2  to  observe  Information  and  less  man  or  equal  to 
HI  to  modlff  Information.  Figure  18  snows  cnaracterlstlcs  of 
tae  ring  bracitets  both  in  terms  of  the  access  modes  used  in 
this  discussion  and  tne  access  modes  used  in  Muitics. 

.Eiecute  (Observe) 

j  iRlne  g _ _ _  iRlt  ^ 

I  Write  (Modify)  _ 

Read  (ubserve) 

figure  le.  Multics  Ring  Mecnanism. 

Continuing  now  with  tne  examination  of  access 
relations,  consider  an  object  tnat  is  classified  as  SECRET. 
Such  an  object  must  be  assigned,  a  ring  bractet  sucn  tnat  it 
maf  be  observed  by  processes  in  ring  0  and  ring  1  only.  R2 
must  tnerefore  be  1.  Tnls  presents  a  problem.  No  matter  wnat 
value  one  may  choose  for  Ri,  a  contradiction  occurs.  If  R1 
is  0  or  1  tnen  TOP  SECRET  processes  may  modify  SECRET  flies 
violating  the  Confinement  Property.  If  Rl  is  greater  than  1, 
tne  restrictions  of  tne  ring  mechanism  would  be  violated 
(viz.,  Rl  >  R2).  Therefore,  one  can  conclude  tnat  this 
assignment  is  not  acceptable. 

Consider  now  tne  only  other  potential  assignment 
scheme  where  the  greatest  lower  bound  of  the  lattice  (the 
UNCLASSIFIED  access  class)  is  assigned  to  ring  0.  Tnls 
assignment  is  Illustrated  in  figure  19. 


One  may  now  attempt  to  assign  ring  bracsets  to  an 
object  classified  SECRET.  A  problem  occurs  immediately.  One 


wants  processes  executing  in  ring  2  to  otjserve  SECRET 
objects,  but  tnen  a  process  in  rin^  fc’  (i.e.,  an  UNCLASSIFIED 
process),  will  also  be  able  to  observe  tae  object.  Tae 
Simple  Security  Condition  cannot  be  enforced  witn  tnls 
assignment,  so  tae  assignment  scneme  is  not  feasible. 


Fleure  19.  Basic  National  Security  Assienment  2. 


Since  neitfler  of  tnese  assienments  are  acceptable, 
and  snifting  tne  ring  assignments  numerically  would  yield 
similar  results,  one  can  see  tnat  no  assignment  will  be 
acceptable.  Therefore,  the  Multlcs  Ring  Mecnanism  is  not 
sufficient  to  enforce  tne  basic  National  Security  policy  for 
compromise. 


iJ.  Subversion  Poilc 


Tne  basic  National  Integrity  policy  l'di\  is  tne  dual 
of  tne  basic  National  Security  policy.  Vnereas  tne  security 
policy  Is  concernel  with  tne  unautnorizea  .  observation  of 
information  or  compromise,  tne  integrity  policy  is  concernea 
witn  tne  unautnorizei  modification  of  information  or 
subversion  as  discussed  in  section  II. 

Consider  first  tne  assignment  of  tne  TOP  SECRET 
access  class  (tne  least  upper  bound  for  tne  lattice 
establlsned  by  tne  policy)  to  Ring  d  (tne  least  upper  bound 
for  tne  dominance  domains  establlsned  by  tne  mecnanlsm).  Tne 
assignment  produced  Is  snown  in  figure  20. 


Fleure  20.  Basic  National  Integrity  Assignment  1. 
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Oae  Tiay  now  examine  tae  access  relations  wnlcn  me 
Multlcs  Rlne  Mecnanlsm  will  permit  (as  saown  in  flpure  19) 
and  test  for  possible  violations  of  tne  policy.  In  so  doing, 
one  encounters  violations  almost  immedlently.  One  wisnes  to 
nave  a  process  executing  in  Ring  1  (i.e.,  a  SfiCRRT  process), 
for  example,  to  be  able  to  ooserve  TOP  SECRET  objects  In 
Ring  43,  but  tne  mecnanlsm  pronlbits  tnis  observation. 
Additionally,  a  SECRET  process  could  observe  CONFIDENTIAL 
information  violating  tne  Integrity  Confinement  Property. 
Tnerefore,  this  assignment  scheme  is  not  feasible. 


Figure  21.  Basic  National  Integrity  Assignment  2. 

Consider  now  tne  only  other  potential  assignment 
according  to  tne  Simple  Assignment  Theorem) 
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scoeme  (viz.. 


wnere  tne  TOP  SECRET  equivalence  class  Is  assigned  to  Rin« 
3.  This  assignment  scnene  is  illustrated  in  figure  2i . 

Examining  tnis  assignment,  consider  an  object  tnat 
is  classified  as  SECRET.  Sucn  an  object  must  be  assigned  a 
ring  bracxet  sucn  tnat  it  may  be  observed  by  processes  in 
Ring  0,  Ring  1  and  Ring  2  only,  so  R2  must  be  assigned  2. 
Rut  if  R2  is  2,  one  is  faced  wltn  a  contradiction  in  tne 
assignment  of  Rl.  If  R1  is  assigned  0,  1  or  2,  tnen  a 
violation  of  tne  simple  Integrity  Condition  occurs  because 
UNCLASSIFIED  subjects  may  tnen  modify  SECRET  objects.  If  P.l 
is  assigned  3,  tne  Ring  Bracitet  constraints  are  violated. 
Therefore,  tnis  assignment  scheme  fails  to  provide  an 
assignment  wnere  me  protection  mechanism  can  enforce  tnis 
policy. 

According  to  tne  Simple  Assignment  Theorem,  there 
are  no  otner  assignments  wortny  of  consideration.  Therefore, 
the  Multics  Ring  Mechanism  is  not  sufficient  to  enforce  tnis 
policy  either. 

So  far,  it  nas  been  snown  tnat  tne  Muitics  ^ing 
Mechanism  is  not  sufficient  to  enforce  the  basic  National 
Security  policy  nor  me  basic  National  Integrity  policy. 
However,  a  Muitics  Security  Kernel  has  been  deslened  [28,29J 
tnat  is  sufficient  to  support  bom  of  these  policies.  This 
may  seem  to  be  a  contradiction  but  it  is  not.  Tne  confusion 
is  dissipated  when  one  asks  tne  question,  "Wnat  form  of 
policy  does  tne  Muitics  Ring  Mechanism  support?” 
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3.  Program  Integrity  Policy 

The  eeneral  form  or  Program  Integrity  policies  was 
Introduced  In  section  II.  Consider  now  the  specific  program 
integrity  policy  shown  in  figure  22. 


Figure  22.  A  Program  Integrity  Policy. 

According  to  tnls  policy,  entitles  are  partitioned 
into  one  of  four  access  classes  designated  as  Dser, 
Supervisor,  tlililty  or  Kernel.  The  sensitivity  of  these 
access  classes  is  specified  as  :  Kernel  >  Supervisor  > 
Otility  >  User.  An  assignment  to  a  Multics  ring  structure  is 
made  as  shown  in  figure  23. 

Recalling  tne  characteristics  of  ring  bracsets  shown 
in  figure  IS,  "Max"  is  designated  as  Ring  0,  the  program 
integrity  access  class  (PI)  as  Rl  and  "Min”  as  R2.  One  may 
note  that  for  this  policy  any  choice  for  R2  greater  than  or 
equal  to  Rl  will  do.  This  analysis,  however,  has  fixed  R2  at 
3. 


According  to  tne  assignment  technique,  one  must  now 


examine  the  access  relations  permitted  by  the  mechanism  and 
test  for  possible  violations  of  tne  policy.  Onllire  previous 
examples,  where  the  mechanism  was  obviously  not  sufficient 
to  support  the  policy  (i.e.,  only  a  single  counter-example 


71 


was  necessary)  mis  example  examines  a  policy  tnat  is  lliceiy 
to  be  supported  by  tne  Multlcs  Sing  Mecnanlsm.  Knowing  tnis, 
it  seems  appropriate  to  present  a  more  careful  approacn  for 


tne  validation  of  tnis  assignment. 


Figure  23.  Program  Integrity  Assignment  1. 

For  simplicity,  one  may  refer  to  (tne  first 
equivalence  class)  as  Kernel  (i.e.,  tne  access  class  tnat 
labels  tnis  equivalence  class  of  subjects  and  objects),  e^ 
as  Supervisor,  as  Utility  and  as  User.  One  may  also 
refer  to  Aq  (me  first  dominance  domain  estabiisned  by  tne 
Multlcs  King  Mecnanlsm)  as  Ring  0,  Aj^  as  Ring  1,  A2  as 
Ring  2  and  A^  as  Ring  3.  Tne  assignment  scneme  consists  of 
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assigning  to  Aq  (Kernel  to  Ring  e),  e^  to  (Supervisor 
to  Rine  1),  62  to  ^2  (Utility  to  Rine  2),  to  A3  (User 
to  Ring  3).  One  can  now  evaluate  tue  access  relations 
permitted  by  tne  Multics  Rin«  Mechanism  and  compare  them 
with  the  policy. 

Examining  the  read  access  first,  one  notes  that  the 
Multics  Ring  Mechanism  provides  no  discrimination  for  read 
access  since  R2  is  fixed  at  3  for  all  objects.  Thus  subjects 
in  Aq,  Aj^,  Aj  or  A3  may  read  objects  in  Aq  ,  A^^ .  A2 

and  A3.  This  corresponds  with  the  access  rights  of  the 
policy  Which  states  that  subjects  in  e^  ,  e^^ ,  e^  or  e^  may 
read  objects  in  e^ ,  e^ ,  and  e^ .  Therefore,  the  mechanism 
is  sufficient  with  respect  to  tne  read  access  relations. 

Next,  examining  the  modify  access  relations  one  may 
observe  that  MAq  MAj^  oc  MA2  MA3.  Thus  a  subject 

in  Aq  may  modify  objects  in  Aq  ,  A^^ ,  or  A3.  This 

corresponds  to  tne  access  rights  of  tne  Kernel  access  class 
in  that  a  subject  in  may  modify  objects  in  Cq  ,  e^ ,  e^  and 
e^ .  Examining  Aj^  ,  one  observes  that  a  subject  in  a^^  may 
modify  objects  in  a,  »  A-  or  a,  but  not  in  a^ •  ^^Is 
corresponds  with  tne  access  rights  of  tne  Supervisor  access 
class  in  that  a  subject  in  e^  may  modify  objects  in  e^^ , 
and  e3  but  not  in  eQ .  Examialng  A^ ,  one  observes  that  a 
subject  in  A2  may  modify  objects  in  a^  or  A3  but  not  in 
Aq  or  Aj^ .  This  corresponds  with  the  access  rights  of 
the  Utility  access  class  in  that  a  subject  in  e2  may  modify 
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Finally 


objects  In  or  but  not  in  or  . 

eia^jlnlng  A^,  one  observes  tnat  a  subject  in  may  only 
modify  objects  In  A^.  This  corresponds  with  the  access 
rights  of  the  Oser  access  class  in  tnat  a  subject  In  e ^ 
may  only  modify  objects  In  e^.  Therefore,  the  Multlcs 
Ring  Mecnanlsm  is  sufficient  to  support  this  policy  with 
respect  to  modify  access  relations. 

Next,  examining  the  execute  access  relations  one  may 


observe  that  XA3 


XAfv.  This  Is  Just 


the  inverse  of  the  modify  access  relations.  Thus  a  subject 
In  A3  may  execute  objects  In  Aq,  A^^,  A2  or  A3.  This 
corresponds  to  the  access  rights  of  the  Oser  access  class  in 


that  a  subject  In  e3  may  execute  objects  in  Oq,  e^^,  63  and 
e3.  Examining  ^3,  one  observes  that  a  subject  in  A3  may 
execute  objects  In  Aq,  Aj^  or  A3  but  not  In  A^.  This 
corresponds  with  the  access  rights  of  the  Utility  access 
class  In  that  a  subject  In  63  may  execute  objects  in  Bq  ,  e^^ 
and  e2  but  not  In  63.  Examining  A^ ,  one  observes  that  a 
subject  In  Aj^  may  execute  objects  In  Aq  or  A^^  tut  not 
In  A3  or  A3.  This  corresponds  with  the  access  rights 
of  the  Supervisor  access  class  in  tnat  a  subject  In  e^^  may 
execute  objects  In  -q  or  ej^  but  not  In  e3  or  63. 
Finally,  examining  Aq  ,  one  observes  that  a  subject  in  Aq 
may  only  execute  objects  in  Aq.  This  corresponds  with  the 
access  rights  of  tne  Kernel  access  class  In  that  a  subject 
in  Bq  may  only  execute  objects  In  ep .  Therefore,  the 
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Multlcs  Rlnst  Mecnanism  Is  sufficient  to  support  tnis  policy 
witn  respect  to  execute  access  relations. 

So  one  may  onserve  tnat  for  eacn  of  tne  access  modes 
(read,  modify  and  execute),  tne  Multics  Rins  Mecftanlsm  is 
sufficient  to  enforce  tne  policy.  Tnerefore,  for  inis 
assignment,  no  violations  are  possible,  tnus  proving  tnat 
tne  'lultics  Ring  Mecnanlsm  is  sufficient  to  support  tnis 
Program  Integrity  policy. 

B.  OTHER  RINS  MECHANISMS 

Tne  Multlcs  Ring  Mecnanism  is  by  no  means  tne  only  form 
of  Rine  Mecnanism.  By  altering  tne  requirements  of  tne  Ring 
Bracicets  and  tne  need  for  a  Gate  Eeeper,  one  can  contemplate 
adapting  tfte  ring  mecbanlsms  to  meet  other  simple 
nierarcnical  policies. 

Consider  using  the  assignment  shown  in  figure  17,  but 
altering  tne  means  of  liscriminatlon  among  objects  such  tnat 
the  Ring  Bracket  is  a  singleton  (Rl).  Following  the  rules 
Shown  in  figure  24,  one  can  adapt  tnis  ring  mechanism  to 
enforce  tne  basic  National  Security  policy. 

Modify 

I  KERNEL _ JiU  MaT* 

Observe 

Figure  24.  Security  Rings. 
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Sinllary,  figure  25  saows  tne  rules  necessary  for  tne 
sane  assignment  as  snown  in  figure  2<£  to  adapt  tnis  ring 
mecnanism  to  meet  tne  basic  National  Integrity  policy. 

,  Observe _ _ 

I  KERNEL _ [rT]  MAT* 

Modify 

Figure  25.  Integrity  Rings. 

To  be  sure,  tnese  brief  suggestions  do  not  completely 
cnaracterlze  a  practical  protection  mecnanism.  However,  it 
appears  tnat  ring  mecnanisms  are  adaptable  for  tne 
enforcement  of  various  simple  nierarcnical  policies. 

C.  CAPABILITT  MECHANISMS 

Considerable  effort  is  currently  underway  to  provide 
"Provably  Secure  Operating  System"  based  upon  tne  capability 
mecnanism  [30,31] .  It  is  important  to  examine  wnat  form  of 
protection  capabilities  actually  provide. 

Capability  mecnanisms  primarily  establisn  two  dominance 
domains  tnat  are  enforced  by  tnis  system  nardware  mecnanism. 
One  domain  consists  of  capabilities,  and  tne  otner  Is 
objects  tnat  are  not  capabilities  sucn  as  segments  and 
directories.  A  process  taAes  no  note  of  tnese  dominance 
domains,  however,  because  all  processes  nave  access  to 
capabilities  as  well  as  otner  types  of  objects.  So  witn 
respect  to  a  process,  tne  capability  mecnanism  provides  no 
inherent  partitioning  of  tne  system  entities  at  all.  In 
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fact,  in  ir7ing  lo  aetermine  tne  structure  of  uornlnance 
donalas  for  non-capaoill ty  oojects,  oce  encounters  a 
veritable  "spagnetti  bowl"  of  domains,  devoid  of  any 
innerent,  unifying  structure.  Thus  a  capability  mecnanism  is 
of  Itself  not  sufficient  for  tne  enforcement  of  any 
non-dlscreti onary  security  policy.  Enforcement  of 
non-dlscretionary  security  policies  (i.e.,  ttiose  of  primary 
Interest  to  National  Defense)  must  be  accomplisnel  by  some 
otner  add-on  mec&anism. 

Tnis  is  not  to  say  mat  a  capability  mecnanism  is  not 
useful.  For  example,  the  mechanism  can  protect  a  security 
Kernel  in  mucn  tne  same  way  as  rings  protect  tne  Kernel  in 
the  Multlcs  design. 

The  usefulness  of  tne  assignment  technique  in  validating 
the  suitability  of  a  protection  mecnanism  to  enforce  a 
security  policy  has  been  examined  in  tnis  section.  The 
validity  of  me  assignment  tecnnique  nas  been  estabisned. 
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71.  CONCLUSION 


This  researcii  nas  explored  tne  foundations  of 
non-discreti onary  security,  discovering  an  effective 
metnodology  for  assessing  tne  sufficiency  of  a  protection 
rtecnanlsm  to  enforce  a  non-discreti  onary  security  policy.  By 
forTiallzlng  tne  notion  of  a  domain  [6,7j  ,  and  using  a  formal 
notion  of  non-dlscretlonary  security  13],  tfte  inseparable 
nature  of  protection  necnanisms  and  security  policies  nas 
been  established.  This  section  considers  some  future 
directions  for  research  and  summarizes  tne  principle 
findings  of  tne  author. 

A.  FUTURB  DIRECTIONS 

Although  this  author's  investigation  has  provided  some 
structure  to  the  complex  nature  of  security,  considerable 
research  is  still  needed.  The  relationsnip  between 
protection  mechanisms  and  other  operating  systems  mechanisms 
is  not  clear.  Sucn  issues  as  serial! za bill ty , 
synchronization  and  distributed  processing  may  add  new 
dimensions  to  tne  meaning  of  protection.  Fundamental 
limitations  regarding  implementation  details  remain  unsnown. 

Additionally,  one  can  consider  tne  formalization  of 
policy  specifications  In  general.  Can  the  enforcement  of  any 
policies  other  than  lattice  policies  be  evaluated?  Can  ail 
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enforceable  policies  be  represented  in  some  common  form  sucn 
as  a  lattice? 

One  of  tne  most  difficult  problems  in  actually  enforcing 
any  security  policy  is  tne  maintenance  of  unique 
non-forgeabie  attributes  [6]  associated  witn  tne  subjects 
and  objects,  k  mecnanism  for  maintainlne  tne  uniqueness  of 
tnese  attributes  may  be  called  an  "isolation  mecnanism" 
because  it  isolates  tnose  subjects  tnat  may  access  tnese 
attributes  from  tnose  tnat  may  not.  Tnis  does  not  prevent 
snaring  of  objects  but  simply  provides  a  means  of  Isolating 
tnese  attributes  from  general  unprotected  usage.  Botn  tne 
capability  mecnanism  [30,31j  and  tne  notion  of  a  ?ate 
(mecnanism)  [9,2ej  appear  to  be  Isolation  mecnanisms.  k 
comprehensive  study  of  tnis  problem  is  beyond  tne  scope  of 
tnis  discussion.  However,  a  few  observations  concerning 
isolation  noted  during  this  research  are  provided. 

Tne  fundamental  principles  upon  wnicn  an  isolation 
mechanism  must  rely  is  tne  notion  of  a  sesment  (l.e.,  an 
atomic  unit  of  information  storage  for  wnicn  tne  access 
class  is  identified)  and  tne  tranquillity  principle  (l.e., 
tne  notion  tnat  tne  access  class  for  a  subject  or  an  object 
does  not  cnange  during  tne  course  of  computations)  [17J  .  If 
tnese  two  principles  are  not  enforced,  it  is  not  clear  now 
one  may  evaluate  tne  enforcement  of  any  non-dlscretionary 
security  policy. 
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Tne  tranquillity  principle  does  not  strictly  apply  to 
processes.  In  Multics,  for  example,  processes  nad  several 
domains  of  execution.  However,  since  a  suoject  is  defined  as 
a  process-domain  pair,  one  mignt  at  first  suspect  tnat  a 
process  executing  in  multiple  domains  does  not  present  a 
security  problem.  Tnis  is  not  always  tne  case,  particularly 
when  dealing  with  policies  that  attempt  to  limit  the 
information  flow  [13j . 

When  attempting  to  enforce  tne  National  Security  Policy 
in  a  multi-user,  multi-process  environment,  wnere  a  process 
executes  in  a  sequential  fashion  (l.e.,  the  process  is 
serializable)  one  can  do  no  better  tnan  to  allow  a  process 
to  proceed  to  its  "nigh  water  mart”  and  then  terminate  at 
that  level.  Any  attempt  to  revert  to  a  less  sensitive  access 
class  will  result  in  a  potential  compromise.  For  example, 
consider  the  compromise  technique  shown  in  figure  26. 

In  this  example,  a  malicious  agent  utilizes  the  feature 
of  sequential  processes  and  the  basic  P7  synchronization 
mechanism  [33]  to  take  tne  "info”  in  Dominance  Domain  2  and 
copy  it  into  Dominance  Domain  1.  In  order  to  do  so,  the 
agent  calls  procedures  placed  in  the  "High”  domain  by 
subversion  [3],  relylne  only  upon  one  process  (i.e.,  PP.OCESS 
0  or  PROCESS  1)  to  return,  thus  providing  the  information  in 
binary  form  to  tne  "low"  domain.  Tnus  by  serialization  and 
process  synchronization  alone,  tne  Isolation  of  tne 
dominance  domains  has  been  compromised. 
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Dominance 

Domain  1  (  Low  ) 

Domlnapce 

Domain  2  (  Hi?n  ) 

Initial  State: 

Info  101  ^ 

Gotit  (3 

Pointerl04500ll 

Execution : 

PROCESS  S  ( "Syncnronlzer” ) 

LI;  P(l); 

Gotit  :=  i; 

Pointer  ;®  Pointer  +  it 

P(2); 

Gotit  :=  0> 
v(3); 

F(4),* 

GO  TO  Li; 

PROCESS  0  f”Get  a  Zero") 

L2:  CALL  ZeroProc 

II  Gotit  *  0,  THEN 

Copy(Pointer )  ;»  0; 

v(i); 

?(2); 

p(3); 

GO  TO  L2; 

PROCESS  1  ("Set  a  One") 

L3:  CALL  OneProc 

II  Gotit  =  0, 

THEN  Copy(Pointer)  :=  i; 
V(l)f 

v(2); 

p<4); 

GO  TO  L3» 

2eroFiQ£ 

IF  Inf 0 (Pointer)  *  0, 
THEN  return; 

Si:  IF  Gotit  *  0, 

THEN  GO  TO  Sit 
RETURN. 

OneProc 

IF  Inf 0  (Pointer '  =  1, 
THEN  return; 

S2;  IF  Gotit  =  e. 

THEN  GO  TO  S2; 
RETURN. 

Final  State; 

■main— 

Info  101  ...  ^ 

Figure  26.  serialization  Problem. 
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Note  tnat  were  tne  processes  to  act  iniepenaentiy  In 
eacn  do^nlnance  domain  (i.e.,  processes  are  serializable  only 
vitn  respect  to  a  given  dominance  domain  or  syncnronl zatl on 
between  two  processes  is  not  possible)  tnls  compromise  couid 
not  occur.  In  general,  tnls  example  snows  tnat 
syncdroni za tl on  of  processes,  serialization  of  processes  and 
secure  computations  are  fundamentally  related  in  some 
fasnlon.  Tne  exact  nature  of  tnls  reiatlonsnip  is  not  clear. 

£.  RESULTS 

Tne  assignment  tecnnique  nas  been  snown  to  be  a  useful 
method  for  valldatlne  tne  sufficiency  of  a  protection 
mecnanlsm  to  enforce  non-discretlonary  security  policies. 
This  method  provides  considerable  Insleht  into  tne  nature  of 
access  control.  One  may  observe  tnat  non-discretlonary 
security  is  dependent  only  upon  tne  dominance  domains 
established  by  tne  systems  mechanisms  and  tneir  associated 
perm  is si ble  access  relations.  Tne  nature  of  tne  computation 
is  of  no  concern. 

Any  non-discretlonary  security  policy  for  wnicn  tne 
access  classes  and  access  relations  can  be  enumerated,  can 
be  enforced  in  a  theoretical  sense.  Actual  implementation, 
however,  is  dependent  upon  tne  systems'  isolation  mechanism. 
No  policy  can  be  enforced,  in  a  practical  sense,  unless  tne 
system  can  maintain  unique  non-f orgeable  attributes. 
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Protection  mecnanlsms  Innerentiy  "mirror"  tne  policies 
tnat  tney  enforce.  Non-discretl onary  Security  policies  form 
a  lattice  of  access  classes  tnat  may  be  mapped  to  an 
Isomorpttlc  image  of  dominance  domains,  innerentiy 
established  by  the  protection  mechanism.  Since  this  nas  ceen 
shown,  one  need  not  Illustrate  separate  lattices  for  both 
policy  and  mechanism.  One  unified  description  for  both  the 
lattice  policy  and  its  image  establisnel  by  tne  protection 
mechanism  is  sufficient  for  .eeneral  systems  deslen 
considerations . 

One  may  also  consider  approacning  tne  assignment 
technique  from  tne  mecnanism  point  of  view.  The  question 
tnen  becomes,  "Given  some  general  Protection  Mecnanism,  wnat 
form  of  policies  will  it  support?"  An  absolute  answer  to 
tnis  question  is,  in  general,  not  available.  However,  one 
can  make  an  evaluation  for  tnose  policies  that  are  of 
current  Interest.  Tnus,  tne  assignment  tecnnique  gives  one  a 
forum  in  which  to  consider  tne  usefulness  or  protection 
mechanisms  for  specific  policies  of  interest. 

"Uniform  protection  mecnanisms,"  l.e.,  tnose  mechanisms 
forming  lattice  structures  of  dominance  domains  wnere  tne 
access  relations  between  any  two  antisymmetric  dominance 
domains  are  identical,  may  be  represented  by  linear  access 
graphs  in  the  same  manner  as  a  policy.  Wnen  tne  linear 
access  graph  for  the  policy  is  similar  to  the  linear  access 
grapn  for  the  mecnanism,  one  can  see  that  for  a  carefully 
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cnosen  assi^ninent  scfteme,  me  protection  mecnanisn  will 
enforce  tne  security  policy. 

One  may  consiler  tne  development  cf  a  taxonomy  of 
uniform  protection  mecnanlsms  based  upon  tne  nature  of  tne 
access  control  tnat  eacn  enforces.  Sucn  a  taxonomy  is  beyond 
tne  scope  of  tnis  discussion,  nowever,  tne  linear  access 
grapns  illustrated  tnrougnout  tnis  text  may  be  neipful  in 
initiating  sucn  an  effort. 

Tne  protection  provided  oy  tne  Multlcs  Ring  Mecnanism 
appears  to  be  precisely  tne  issue  tnat  Wuif,  Jones  and  tne 
otner  designers  of  tne  "HYDRa"  system  were  attempting  to 
understand  [lej .  They  introduce  tnelr  discussion  by  first 
sayine  : 


"protection  is,  in  our  view,  a  mecnanlsm."  [18J 


Tnelr  discussion  tnen  proceeds  to  mate  tne  following 
general  statement  relative  to  tne  Multlcs  rings: 


'Our  rejection  of  nlerarcnlcal  system 
structures  and  especially  ones  wnicn  employ  a 
single  nlerarcnlcal  relation  for  all  aspects  of 
system  interaction,  is  also,  in  part,  a 
consequence  of  the  distinction  between  protection 
and  security.  A  failure  to  dlstlngulsn  tnese 
issues  coupled  with  a  strict  nlerarcnlcal 
structure  leads  inevitably  to  a  succession  of 
increasingly  privileged  system^  components,  and 
ultimately  to  a  "most  privileged"  one,  wnicn  gain 
their  privilege  exclusively  by  virtue  of  their 
position  in  me  hierarchy.  Sucn  structures  are 
inherently  wrong  ..."  [i9] 
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Had  t&e  assienment  tecnnique  been  available  to  tne 
autnors  of  tne  above  statement,  tney  would  nave  been 
afforded  a  means  of  expressing  tfteir  views  more  precisely 
tnan  tne  ambiguous  pnrase  "innerentiy  wrong".  Tne  assignment 
tecnnique  provides  a  precise  means  for  clearly  formulating 
sucn  an  observation  and  evaluating  its  validity.  As  snown  in 
section  7,  and  in  agreement  witn  rfulfs'  statement,  tne 
Multics  Hlng  Mecnanlsm  is  "innerentiy  wrong'*  witn  respect  to 
compromise  policies.  On  tne  oiner  band,  tne  Multics  Rlne 
Mecnanism  is  ".lust  rignt"  as  a  means  of  enforcing  a  program 
integrity  policy  or  assisting  in  tne  enforcement  of  tne 
systems  blerarchical  as  well  as  non-bierarcnical  security 
policies  (viz,,  via  Security  Kernels). 

Additionally,  in  tne  same  report  [ISJ  tne  autnors  matte 
tne  following  observation  witn  respect  to  tneir  overall 
design  metnodclogy  ; 

"Among  tne  major  causes  of  our  inability  to 
experiment  witn,  and  adapt,  existing  operating 
systems  is  tneir  failure  to  properly  separate 
mecnanisms  from  policy."  [lej 

The  assienment  technique  nas  shown,  however,  that 
lattice  security  policies  and  protection  mecnanisms  tnat 
enforce  these  policies  are  Inextrlcablely  related. 
Recognizing  tnls  inseparability  should  provide  conslderAPi-e::.:-^ 
insight  into  current  efforts  in  this  area. 
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Overdii,  assignment  researcn  nas  provided  a  matnematicai 
metnodology  for  unifying  tne  discussion  of  security  related 
issues.  One  may  now  properly  refer  to  an  access  mode  as  a 
realization  of  an  access  rignt,  a  dominance  domain  as  a 
realization  of  an  access  class  and  a  protection  mecnanlsm  as 
a  realization  of  a  security  policy. 
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